perm filename CLCLEA.MSG[COM,LSP]19 blob
sn#881549 filedate 1990-01-29 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00439 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00062 00002
C00063 00003 ∂13-Mar-89 1254 CL-Cleanup-mailer amendments to already passed issues
C00065 00004 ∂13-Mar-89 1352 CL-Cleanup-mailer Issue: LOAD-OBJECTS (Version 3)
C00072 00005 ∂13-Mar-89 1448 CL-Cleanup-mailer Issue: LOAD-TRUENAME (Version 1)
C00080 00006 ∂13-Mar-89 1457 CL-Cleanup-mailer Issue CLOS-CONDITIONS, v4
C00082 00007 ∂13-Mar-89 1457 CL-Cleanup-mailer gls cleanups
C00084 00008 ∂13-Mar-89 1500 CL-Cleanup-mailer Issue ERROR-CHECKING-IN-NUMBERS-CHAPTER
C00086 00009 ∂13-Mar-89 1501 CL-Cleanup-mailer Issue SUBTYPEP-TOO-VAGUE
C00089 00010 ∂13-Mar-89 1502 CL-Cleanup-mailer Issue PEEK-CHAR-READ-CHAR-ECHO
C00095 00011 ∂13-Mar-89 1457 CL-Compiler-mailer Issue LOCALLY-TOP-LEVEL, v1
C00097 00012 ∂13-Mar-89 1557 CL-Cleanup-mailer Issue LOCALLY-TOP-LEVEL, v1
C00100 00013 ∂13-Mar-89 1726 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL (Version 9)
C00102 00014 ∂13-Mar-89 1737 CL-Compiler-mailer Re: Issue: LOAD-OBJECTS (Version 3)
C00107 00015 ∂13-Mar-89 1754 CL-Compiler-mailer Re: Issue: LOAD-OBJECTS (Version 3)
C00111 00016 ∂14-Mar-89 0738 CL-Cleanup-mailer Re: Issue PEEK-CHAR-READ-CHAR-ECHO
C00115 00017 ∂14-Mar-89 0738 CL-Cleanup-mailer More re: PEEK-CHAR-READ-CHAR-ECHO
C00117 00018 ∂14-Mar-89 0756 CL-Cleanup-mailer Re: Issue: DESTRUCTURING-BIND (Version 2)
C00119 00019 ∂14-Mar-89 0835 CL-Cleanup-mailer Re: Issue: CONDITION-RESTARTS (Version 1)
C00121 00020 ∂14-Mar-89 0923 CL-Cleanup-mailer More re: PEEK-CHAR-READ-CHAR-ECHO
C00124 00021 ∂14-Mar-89 1104 CL-Cleanup-mailer Re: Issue IGNORE-VARIABLE, v1
C00133 00022 ∂14-Mar-89 1253 CL-Cleanup-mailer re: PATHNAME-PRINT-READ, v1
C00136 00023 ∂14-Mar-89 1317 CL-Cleanup-mailer Re: PATHNAME-PRINT-READ, v1
C00139 00024 ∂14-Mar-89 1344 CL-Cleanup-mailer Re: Issue: LOAD-TRUENAME (Version 1)
C00141 00025 ∂14-Mar-89 1344 CL-Cleanup-mailer Re: Issue: CLOS-CONDITIONS (Version 4)
C00144 00026 ∂14-Mar-89 1344 CL-Cleanup-mailer Issue: LOAD-TRUENAME (Version 1)
C00146 00027 ∂14-Mar-89 1358 CL-Cleanup-mailer Issue: TIME-ZONE-NON-INTEGER
C00148 00028 ∂14-Mar-89 1505 CL-Cleanup-mailer Issue: ERROR-NOT-HANDLED (Version 1)
C00150 00029 ∂14-Mar-89 1612 CL-Cleanup-mailer TYPE-OF-UNDERCONSTRAINED, version 4
C00160 00030 ∂14-Mar-89 1613 CL-Cleanup-mailer SYMBOL-MACROLET-SEMANTICS, version 6
C00172 00031 ∂14-Mar-89 1731 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
C00175 00032 ∂14-Mar-89 1731 CL-Cleanup-mailer RE: Cleanup Issue Status
C00180 00033 ∂14-Mar-89 1732 CL-Cleanup-mailer revised: Cleanup Issue Status
C00184 00034 ∂14-Mar-89 1732 CL-Cleanup-mailer Issue: PRETTY-PRINT-INTERFACE (Version 1)
C00186 00035 ∂14-Mar-89 1732 CL-Compiler-mailer Re: Potential issue: MACRO-SPECIAL-FORMS
C00188 00036 ∂14-Mar-89 1743 CL-Cleanup-mailer Issue: FORMAT-PLURALS (not yet submitted)
C00197 00037 ∂14-Mar-89 1756 CL-Cleanup-mailer Re: Issue: COPY-SYMBOL-PRINT-NAME (Version 1)
C00199 00038 ∂14-Mar-89 1812 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
C00202 00039 ∂15-Mar-89 0542 CL-Cleanup-mailer Issue: COPY-SYMBOL-PRINT-NAME
C00207 00040 ∂15-Mar-89 0549 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 7)
C00219 00041 ∂15-Mar-89 0641 CL-Cleanup-mailer Re: Issue: OPTIMIZE-SAFETY (Version 1)
C00221 00042 ∂15-Mar-89 0720 CL-Cleanup-mailer Re: Issue ERROR-CHECKING-IN-NUMBERS-CHAPTER
C00224 00043 ∂15-Mar-89 0720 CL-Cleanup-mailer
C00265 00044 ∂15-Mar-89 0741 CL-Cleanup-mailer Re: Issue: PLUS-ABNORMAL (Version 1)
C00269 00045 ∂15-Mar-89 0817 CL-Cleanup-mailer Cleanup Issue Status
C00271 00046 ∂15-Mar-89 0845 CL-Cleanup-mailer Re: Cleanup Issue Status
C00274 00047 ∂15-Mar-89 0921 CL-Cleanup-mailer Re: Cleanup Issue Status
C00278 00048 ∂15-Mar-89 0930 CL-Cleanup-mailer Issue: PRETTY-PRINT-INTERFACE (Version 1)
C00281 00049 ∂15-Mar-89 0934 CL-Cleanup-mailer RE: Cleanup Issue Status
C00284 00050 ∂15-Mar-89 0936 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C00286 00051 ∂15-Mar-89 0947 CL-Cleanup-mailer Issue: COPY-SYMBOL-PRINT-NAME
C00288 00052 ∂15-Mar-89 0959 CL-Cleanup-mailer Issue: TIME-ZONE-NON-INTEGER
C00290 00053 ∂15-Mar-89 0948 X3J13-mailer Issue: GENSYM-NAME-STICKINESS (Version 1)
C00292 00054 ∂15-Mar-89 1045 CL-Cleanup-mailer Issue: GENSYM-NAME-STICKINESS (Version 1)
C00297 00055 ∂15-Mar-89 1057 CL-Cleanup-mailer Issue LOOP-AND-DISCREPANCY, version 1
C00303 00056 ∂15-Mar-89 1111 CL-Cleanup-mailer Issue: COPY-SYMBOL-COPY-PLIST
C00305 00057 ∂15-Mar-89 1127 CL-Cleanup-mailer Issue: REAL-NUMBER-TYPE (version 3)
C00318 00058 ∂15-Mar-89 1138 CL-Cleanup-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
C00338 00059 ∂15-Mar-89 1145 CL-Cleanup-mailer Issue: REAL-NUMBER-TYPE (version 3)
C00342 00060 ∂15-Mar-89 1147 CL-Cleanup-mailer Issue: MAKE-STRING-FILL-POINTER (Version 1)
C00347 00061 ∂15-Mar-89 1208 CL-Cleanup-mailer Issue status
C00349 00062 ∂15-Mar-89 1227 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL (Version 9)
C00352 00063 ∂15-Mar-89 1229 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
C00355 00064 ∂15-Mar-89 1256 CL-Cleanup-mailer PRETTY-PRINT-INTERFACE, version 3 (supersedes 2 sent an hour ago!)
C00379 00065 ∂15-Mar-89 1306 CL-Cleanup-mailer Issue: GENSYM-NAME-STICKINESS, version 2
C00387 00066 ∂15-Mar-89 1449 CL-Cleanup-mailer Issue SUBTYPEP-TOO-VAGUE, version 5
C00397 00067 ∂15-Mar-89 1454 CL-Cleanup-mailer [gls: Issue SUBTYPEP-TOO-VAGUE, version 5]
C00408 00068 ∂15-Mar-89 1756 CL-Cleanup-mailer Re: Issue LOCALLY-TOP-LEVEL, v1
C00410 00069 ∂15-Mar-89 1907 CL-Cleanup-mailer Re: Issue STREAM-ACCESS
C00412 00070 ∂16-Mar-89 0523 CL-Cleanup-mailer Re: Issue: GENSYM-NAME-STICKINESS, version 2
C00414 00071 ∂16-Mar-89 0646 CL-Cleanup-mailer Issue: GENSYM-NAME-STICKINESS, version 2
C00416 00072 ∂16-Mar-89 0807 CL-Cleanup-mailer Re: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)
C00419 00073 ∂16-Mar-89 0827 CL-Cleanup-mailer Re: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)
C00422 00074 ∂16-Mar-89 0831 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL (Version 9)
C00424 00075 ∂16-Mar-89 0917 CL-Cleanup-mailer Issue LOOP-AND-DISCREPANCY, version 1
C00426 00076 ∂16-Mar-89 0932 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL (Version 9)
C00429 00077 ∂16-Mar-89 1044 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL (Version 9)
C00431 00078 ∂16-Mar-89 1115 CL-Cleanup-mailer Issue: GENSYM-NAME-STICKINESS, version 2
C00434 00079 ∂16-Mar-89 1143 CL-Cleanup-mailer Re: DRAFT Issue: CONDITION-RESTARTS (Version 1)
C00436 00080 ∂16-Mar-89 1234 CL-Cleanup-mailer Re: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)
C00440 00081 ∂16-Mar-89 1252 CL-Cleanup-mailer DEFAULT-CASE
C00448 00082 ∂16-Mar-89 1318 CL-Cleanup-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)
C00451 00083 ∂16-Mar-89 1338 CL-Cleanup-mailer Issue: ENVIRONMENT-ENQUIRY (not submitted)
C00453 00084 ∂16-Mar-89 1338 CL-Cleanup-mailer Re: Issue EQUALP-GENERIC
C00454 00085 ∂16-Mar-89 1440 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL (Version 9)
C00456 00086 ∂16-Mar-89 1518 CL-Cleanup-mailer DEFAULT-CASE
C00459 00087 ∂16-Mar-89 1555 CL-Cleanup-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)
C00463 00088 ∂16-Mar-89 1605 CL-Cleanup-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)
C00468 00089 ∂16-Mar-89 1802 CL-Cleanup-mailer Issue: TYPE-OF-UNDERCONSTRAINED, v.5
C00479 00090 ∂16-Mar-89 2116 CL-Cleanup-mailer Re: Issue: EXPT-ZERO-ZERO (Version 1)
C00481 00091 ∂16-Mar-89 2212 CL-Cleanup-mailer Issue: FIXNUM-NON-PORTABLE, v.5
C00490 00092 ∂16-Mar-89 2253 CL-Cleanup-mailer Re: DEFAULT-CASE
C00495 00093 ∂16-Mar-89 2310 CL-Cleanup-mailer Re: Issue: IN-SYNTAX (Version 1)
C00497 00094 ∂17-Mar-89 0009 CL-Cleanup-mailer Cleanup Issue Status List
C00543 00095 ∂17-Mar-89 0823 CL-Cleanup-mailer Re: DEFAULT-CASE
C00548 00096 ∂17-Mar-89 0838 CL-Cleanup-mailer Issue: FUNCTION-COERCE-TIME (Version 2)
C00550 00097 ∂17-Mar-89 0847 CL-Cleanup-mailer Re: DEFAULT-CASE
C00555 00098 ∂17-Mar-89 0859 CL-Cleanup-mailer Re: issue HASH-TABLE-PRINTED-REPRESENTATION, v.2
C00560 00099 ∂17-Mar-89 0910 CL-Cleanup-mailer Re: Issue: COERCE-INCOMPLETE (Version 3)
C00564 00100 ∂17-Mar-89 1032 CL-Cleanup-mailer DYNAMIC-EXTENT
C00567 00101 ∂17-Mar-89 1044 CL-Cleanup-mailer Re: DEFAULT-CASE
C00572 00102 ∂17-Mar-89 1046 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL (Version 9)
C00575 00103 ∂17-Mar-89 1100 CL-Cleanup-mailer Issue: CONDITION-RESTARTS (Version 1)
C00578 00104 ∂17-Mar-89 1101 CL-Cleanup-mailer Issue: CONDITION-RESTARTS (Version 1)
C00581 00105 ∂17-Mar-89 1205 CL-Cleanup-mailer Issue: IN-SYNTAX (Version 1)
C00583 00106 ∂17-Mar-89 1214 CL-Cleanup-mailer Issue LOOP-AND-DISCREPANCY, version 1
C00585 00107 ∂17-Mar-89 1214 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
C00588 00108 ∂17-Mar-89 1214 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C00593 00109 ∂17-Mar-89 1229 CL-Cleanup-mailer DYNAMIC-EXTENT
C00597 00110 ∂17-Mar-89 1254 CL-Cleanup-mailer Re: DEFAULT-CASE
C00603 00111 ∂17-Mar-89 1254 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C00606 00112 ∂17-Mar-89 1257 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C00609 00113 ∂17-Mar-89 1327 CL-Cleanup-mailer DYNAMIC-EXTENT
C00613 00114 ∂17-Mar-89 1337 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
C00628 00115 ∂17-Mar-89 1346 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
C00633 00116 ∂17-Mar-89 1410 CL-Cleanup-mailer Re: Issue: EXPT-ZERO-ZERO (Version 1)
C00636 00117 ∂17-Mar-89 1541 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C00640 00118 ∂17-Mar-89 1555 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
C00643 00119 ∂17-Mar-89 1618 CL-Cleanup-mailer Issue: CONDITION-RESTARTS (Version 1)
C00651 00120 ∂17-Mar-89 1627 CL-Cleanup-mailer Issue: PACKAGE-FUNCTION-CONSISTENCY (version 4)
C00658 00121 ∂17-Mar-89 1600 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C00660 00122 ∂17-Mar-89 1613 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C00663 00123 ∂17-Mar-89 1657 CL-Cleanup-mailer Issue: FIXNUM-NON-PORTABLE, v.5
C00666 00124 ∂17-Mar-89 1656 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C00672 00125 ∂17-Mar-89 1839 CL-Cleanup-mailer Re: Issue: FIXNUM-NON-PORTABLE, v.5
C00673 00126 ∂17-Mar-89 1949 CL-Cleanup-mailer Re: Issue: CONDITION-RESTARTS (Version 1)
C00675 00127 ∂17-Mar-89 2009 CL-Cleanup-mailer Issue: DEFMACRO-LAMBDA-LIST, v.2
C00684 00128 ∂17-Mar-89 2126 CL-Cleanup-mailer New issue: WITH-OPEN-FILE-DOES-NOT-EXIST
C00690 00129 ∂17-Mar-89 2128 CL-Cleanup-mailer Re: DEFAULT-CASE
C00692 00130 ∂17-Mar-89 2140 CL-Cleanup-mailer Issue: TYPE-OF-UNDERCONSTRAINED, v.5
C00698 00131 ∂17-Mar-89 2153 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
C00701 00132 ∂17-Mar-89 2223 CL-Cleanup-mailer Re: Issue: TYPE-OF-UNDERCONSTRAINED, v.5
C00704 00133 ∂17-Mar-89 2235 CL-Cleanup-mailer Issue: PRETTY-PRINT-INTERFACE (version 3)
C00711 00134 ∂17-Mar-89 2254 CL-Cleanup-mailer Re: Issue: LOAD-OBJECTS (Version 3)
C00717 00135 ∂17-Mar-89 2300 CL-Cleanup-mailer Re: Issue: TYPE-OF-UNDERCONSTRAINED, v.5
C00721 00136 ∂17-Mar-89 2320 CL-Cleanup-mailer Re: Issue: PLUS-ABNORMAL (Version 1)
C00722 00137 ∂17-Mar-89 2357 CL-Cleanup-mailer Re: environment argument for SUBTYPEP
C00724 00138 ∂18-Mar-89 0026 CL-Cleanup-mailer [cl-cleanup@sail.stanford.edu: Issue:
C00736 00139 ∂18-Mar-89 0122 CL-Cleanup-mailer Cleanup Issue Status List
C00780 00140 ∂18-Mar-89 0216 CL-Cleanup-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)
C00801 00141 ∂18-Mar-89 1708 CL-Cleanup-mailer *DRAFT* Issue: DESTRUCTURING-BIND, v.2
C00803 00142 ∂18-Mar-89 1720 CL-Cleanup-mailer Issue DESCRIBE-UNDERSPECIFIED, v.1
C00806 00143 ∂18-Mar-89 2312 CL-Cleanup-mailer Issue: DEFMACRO-LAMBDA-LIST, v.2
C00809 00144 ∂19-Mar-89 1058 CL-Cleanup-mailer Issue: HASH-TABLE-ACCESS (version 2)
C00812 00145 ∂20-Mar-89 1229 CL-Cleanup-mailer Re: Issue: PRETTY-PRINT-INTERFACE (version 3)
C00816 00146 ∂20-Mar-89 1236 CL-Cleanup-mailer Re: Issue: PRETTY-PRINT-INTERFACE (version 3)
C00820 00147 ∂20-Mar-89 1241 CL-Cleanup-mailer Issue: COMPLEX-RATIONAL-RESULT (version 1)
C00826 00148 ∂20-Mar-89 1241 CL-Cleanup-mailer Issue: HASH-TABLE-SIZE (version 1)
C00831 00149 ∂20-Mar-89 1242 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-VALUE (version 1)
C00844 00150 ∂20-Mar-89 1241 CL-Cleanup-mailer Issue: COMMON-TYPE (version 1)
C00848 00151 ∂20-Mar-89 1325 CL-Cleanup-mailer Re: Issue: LOAD-OBJECTS (Version 3)
C00850 00152 ∂20-Mar-89 1415 CL-Cleanup-mailer Re: Issue: PRETTY-PRINT-INTERFACE (version 3)
C00855 00153 ∂20-Mar-89 1427 CL-Cleanup-mailer Re: Issue: LOAD-OBJECTS (Version 3)
C00857 00154 ∂20-Mar-89 1437 CL-Cleanup-mailer Issue: COMMON-TYPE (version 1)
C00859 00155 ∂20-Mar-89 1438 CL-Cleanup-mailer Issue: COMMON-TYPE (version 1)
C00861 00156 ∂20-Mar-89 1507 CL-Cleanup-mailer Issue: COMPLEX-RATIONAL-RESULT (version 1)
C00863 00157 ∂20-Mar-89 1512 CL-Cleanup-mailer Issue: HASH-TABLE-SIZE (version 1)
C00865 00158 ∂20-Mar-89 1556 CL-Cleanup-mailer Issue: PRETTY-PRINT-INTERFACE (version 3)
C00872 00159 ∂20-Mar-89 1605 CL-Cleanup-mailer Issue: FIXNUM-NON-PORTABLE, v.5
C00876 00160 ∂20-Mar-89 1841 CL-Cleanup-mailer Issue: PRETTY-PRINT-INTERFACE (version 3)
C00884 00161 ∂20-Mar-89 2059 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-VALUE (version 1)
C00888 00162 ∂21-Mar-89 0845 CL-Cleanup-mailer Issue: GENSYM-NAME-STICKINESS (Version 3)
C00897 00163 ∂21-Mar-89 1503 CL-Cleanup-mailer New cleanup issues
C00899 00164 ∂21-Mar-89 1601 CL-Cleanup-mailer New issue: WITH-OPEN-FILE-DOES-NOT-EXIST
C00901 00165 ∂21-Mar-89 1643 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-VALUE (version 1)
C00908 00166 ∂21-Mar-89 1752 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-VALUE (version 1)
C00914 00167 ∂21-Mar-89 2227 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-VALUE (version 1)
C00916 00168 ∂22-Mar-89 1054 CL-Cleanup-mailer PRETTY-PRINT-INTERFACE, version 4
C00954 00169 ∂22-Mar-89 1057 CL-Cleanup-mailer PRETTY-PRINT-INTERFACE, version 4
C01019 00170 ∂22-Mar-89 1104 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
C01025 00171 ∂22-Mar-89 1612 CL-Cleanup-mailer Issue: PRETTY-PRINT-INTERFACE, version 4
C01027 00172 ∂22-Mar-89 2239 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
C01031 00173 ∂23-Mar-89 0645 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)
C01034 00174 ∂23-Mar-89 0804 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)
C01037 00175 ∂23-Mar-89 0805 CL-Cleanup-mailer Re: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
C01040 00176 ∂23-Mar-89 0820 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)
C01043 00177 ∂23-Mar-89 0919 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)
C01046 00178 ∂23-Mar-89 1112 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
C01049 00179 ∂23-Mar-89 1132 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
C01052 00180 ∂23-Mar-89 1205 CL-Cleanup-mailer string OK for :CONC-NAME in DEFSTRUCT?
C01055 00181 ∂23-Mar-89 1225 CL-Cleanup-mailer Meeting 1 hour before plenary session?
C01057 00182 ∂23-Mar-89 1504 CL-Cleanup-mailer Meeting 1 hour before plenary session?
C01059 00183 ∂23-Mar-89 1518 CL-Cleanup-mailer Issue: READ-CASE-SENSITIVITY (Version 2)
C01076 00184 ∂23-Mar-89 1534 CL-Cleanup-mailer Re: New cleanup issues
C01078 00185 ∂23-Mar-89 1538 CL-Cleanup-mailer Re: Issue: FIXNUM-NON-PORTABLE, v.5
C01087 00186 ∂23-Mar-89 1538 CL-Cleanup-mailer The Revised Cleanup Issue Status List
C01121 00187 ∂23-Mar-89 1656 CL-Cleanup-mailer Issue: READ-CASE-SENSITIVITY (Version 2)
C01125 00188 ∂23-Mar-89 1503 CL-Windows-mailer Issue STREAM-DEFINITION-BY-USER (V1)
C01168 00189 ∂23-Mar-89 1813 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 2)
C01171 00190 ∂23-Mar-89 1518 CL-Cleanup-mailer Issue: DIRECTORY-DOES-TOO-MUCH
C01178 00191 ∂23-Mar-89 1534 CL-Cleanup-mailer Re: Issue: GENSYM-NAME-STICKINESS (Version 3)
C01179 00192 ∂23-Mar-89 2050 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 2)
C01187 00193 ∂23-Mar-89 2232 CL-Cleanup-mailer Issue: DIRECTORY-DOES-TOO-MUCH
C01192 00194 ∂24-Mar-89 0745 CL-Cleanup-mailer Re: Issue: DIRECTORY-DOES-TOO-MUCH
C01195 00195 ∂24-Mar-89 0807 CL-Cleanup-mailer Meeting 1 hour before plenary session?
C01198 00196 ∂24-Mar-89 1015 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 2)
C01200 00197 ∂24-Mar-89 1024 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 2)
C01204 00198 ∂24-Mar-89 1344 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 2)
C01209 00199 ∂25-Mar-89 1209 CL-Cleanup-mailer Cleanup Meeting
C01211 00200 ∂29-Mar-89 1535 CL-Cleanup-mailer new version of LOAD-TRUENAME
C01221 00201 ∂29-Mar-89 1550 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND, v.3
C01234 00202 ∂04-Apr-89 0804 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE
C01235 00203 ∂04-Apr-89 0805 CL-Cleanup-mailer Issue: BREAK-ON-WARNINGS-OBSOLETE
C01237 00204 ∂04-Apr-89 0805 CL-Cleanup-mailer Issue: CLOS-CONDITIONS
C01238 00205 ∂04-Apr-89 0808 CL-Cleanup-mailer Issue: CLOS-MACRO-COMPILATION
C01240 00206 ∂04-Apr-89 0809 CL-Cleanup-mailer Issue: CLOSED-STREAM-OPERATIONS
C01242 00207 ∂04-Apr-89 0809 CL-Cleanup-mailer Issue: COERCE-INCOMPLETE
C01244 00208 ∂04-Apr-89 0816 CL-Cleanup-mailer Issue: COMMON-TYPE
C01245 00209 ∂04-Apr-89 0817 CL-Cleanup-mailer Issue: COMPILE-FILE-SYMBOL-HANDLING
C01247 00210 ∂04-Apr-89 0817 CL-Cleanup-mailer Issue: COMPILE-ENVIRONMENT-CONSISTENCY
C01249 00211 ∂04-Apr-89 0823 CL-Cleanup-mailer COMPILE-FILE-SYMBOL-HANDLING, COMPILE-ENVIRONMENT-CONSISTENCY
C01251 00212 ∂04-Apr-89 0832 CL-Cleanup-mailer Issue: COMPLEX-RATIONAL-RESULT
C01252 00213 ∂04-Apr-89 0833 CL-Cleanup-mailer Issue: CONDITION-RESTARTS
C01254 00214 ∂04-Apr-89 0834 CL-Cleanup-mailer Issue: COPY-SYMBOL-COPY-PLIST
C01255 00215 ∂04-Apr-89 0834 CL-Cleanup-mailer Issue: COPY-SYMBOL-COPY-PRINT-NAME
C01256 00216 ∂04-Apr-89 0835 CL-Cleanup-mailer Issue: DECLARE-FUNCTION-AMBIGUITY
C01258 00217 ∂04-Apr-89 0842 CL-Cleanup-mailer Issue: DEFINE-OPTIMIZER
C01260 00218 ∂04-Apr-89 0852 CL-Cleanup-mailer Issue: DEFMACRO-LAMBDA-LIST
C01262 00219 ∂04-Apr-89 0855 CL-Cleanup-mailer Issue: DEFMACRO-LAMBDA-LIST
C01265 00220 ∂04-Apr-89 0855 CL-Cleanup-mailer Issue: DESCRIBE-UNDERSPECIFIED
C01267 00221 ∂04-Apr-89 0857 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND
C01269 00222 ∂04-Apr-89 1027 CL-Cleanup-mailer issue DYNAMIC-EXTENT-FUNCTION, version 1
C01275 00223 ∂04-Apr-89 1110 CL-Cleanup-mailer Issue: DYNAMIC-EXTENT
C01279 00224 ∂04-Apr-89 1111 CL-Cleanup-mailer Issue: EQUALP-GENERIC
C01280 00225 ∂04-Apr-89 1114 CL-Cleanup-mailer Issue: ERROR-CHECKING-IN-NUMBERS-CHAPTER
C01283 00226 ∂04-Apr-89 1115 CL-Cleanup-mailer Issue: ERROR-NOT-HANDLED
C01285 00227 ∂04-Apr-89 1117 CL-Cleanup-mailer Issue: FUNCTION-COERCE-TIME
C01286 00228 ∂04-Apr-89 1125 CL-Cleanup-mailer Issue: EXIT-EXTENT
C01288 00229 ∂04-Apr-89 1127 CL-Cleanup-mailer Re: Issue: DYNAMIC-EXTENT
C01291 00230 ∂04-Apr-89 1127 CL-Cleanup-mailer Issue: FUNCTION-NAME
C01294 00231 ∂04-Apr-89 1133 CL-Cleanup-mailer Re: Issue: DYNAMIC-EXTENT
C01296 00232 ∂04-Apr-89 1133 CL-Cleanup-mailer Issue: GENSYM-NAME-STICKINESS
C01298 00233 ∂04-Apr-89 1147 CL-Cleanup-mailer Issue: HASH-TABLE-ACCESS
C01301 00234 ∂04-Apr-89 1148 CL-Cleanup-mailer Issue: HASH-TABLE-SIZE
C01303 00235 ∂04-Apr-89 1149 CL-Cleanup-mailer Issue: IN-PACKAGE-FUNCTIONALITY
C01306 00236 ∂04-Apr-89 1153 CL-Cleanup-mailer Issue: IN-SYNTAX
C01309 00237 ∂04-Apr-89 1156 CL-Cleanup-mailer Issue: LISP-PACKAGE-NAME
C01311 00238 ∂04-Apr-89 1200 CL-Cleanup-mailer Issue: LISP-SYMBOL-REDEFINITION
C01314 00239 ∂04-Apr-89 1206 CL-Cleanup-mailer Issue: LOAD-OBJECTS (Version 4)
C01337 00240 ∂04-Apr-89 1217 CL-Cleanup-mailer Issue: LOAD-TRUENAME
C01341 00241 ∂04-Apr-89 1219 CL-Cleanup-mailer Issue: LOCALLY-TOP-LEVEL
C01343 00242 ∂04-Apr-89 1219 CL-Cleanup-mailer Issue: LOOP-AND-DISCREPANCY
C01344 00243 ∂04-Apr-89 1221 CL-Cleanup-mailer Issue: MACRO-ENVIRONMENT-EXTENT
C01346 00244 ∂04-Apr-89 1221 CL-Cleanup-mailer Issue: MAKE-STRING-FILL-POINTER
C01348 00245 ∂04-Apr-89 1222 CL-Cleanup-mailer Issue: PACKAGE-FUNCTION-CONSISTENCY
C01350 00246 ∂04-Apr-89 1226 CL-Cleanup-mailer Issue: PATHNAME-LOGICAL
C01352 00247 ∂04-Apr-89 1227 CL-Cleanup-mailer Issue: PATHNAME-PRINT-READ
C01354 00248 ∂04-Apr-89 1227 CL-Cleanup-mailer Issue: PATHNAME-CANONICAL-TYPE
C01356 00249 ∂04-Apr-89 1231 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST
C01357 00250 ∂04-Apr-89 1232 CL-Cleanup-mailer Issue: PEEK-CHAR-READ-CHAR-ECHO
C01359 00251 ∂04-Apr-89 1233 CL-Cleanup-mailer Issue: PRETTY-PRINT-INTERFACE
C01360 00252 ∂04-Apr-89 1235 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-CASE
C01362 00253 ∂04-Apr-89 1238 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL
C01365 00254 ∂04-Apr-89 1238 CL-Cleanup-mailer Issue: READ-CASE-SENSITIVITY
C01367 00255 ∂04-Apr-89 1240 CL-Cleanup-mailer Issue: READ-DELIMITED-LIST-EOF
C01369 00256 ∂04-Apr-89 1242 CL-Cleanup-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 6)
C01371 00257 ∂04-Apr-89 1244 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-VALUE
C01372 00258 ∂04-Apr-89 1244 CL-Cleanup-mailer Issue: SETF-MULTIPLE-STORE-VARIABLES
C01374 00259 ∂04-Apr-89 1249 CL-Cleanup-mailer Issue: SYMBOL-MACROLET-SEMANTICS
C01377 00260 ∂04-Apr-89 1249 CL-Cleanup-mailer Issue: THE-AMBIGUITY
C01378 00261 ∂04-Apr-89 1252 CL-Cleanup-mailer Issue: TIME-ZONE-NON-INTEGER
C01381 00262 ∂04-Apr-89 1253 CL-Cleanup-mailer Issue: PATHNAME-SYNTAX-ERROR-TIME
C01382 00263 ∂04-Apr-89 1256 CL-Cleanup-mailer Issue: PATHNAME-WILD
C01383 00264 ∂04-Apr-89 1258 CL-Cleanup-mailer Issue: WITH-COMPILATION-UNIT
C01385 00265 ∂04-Apr-89 1301 CL-Cleanup-mailer Issue: PRINT-CASE-PRINT-ESCAPE-INTERACTION
C01387 00266 ∂04-Apr-89 1301 CL-Cleanup-mailer Issue: EXIT-EXTENT (version 7)
C01412 00267 ∂04-Apr-89 1301 CL-Cleanup-mailer Issue: PRINT-CIRCLE-SHARED
C01414 00268 ∂04-Apr-89 1304 CL-Cleanup-mailer Issue: REAL-NUMBER-TYPE
C01416 00269 ∂04-Apr-89 1309 CL-Cleanup-mailer Issue: REQUIRE-PATHNAME-DEFAULTS
C01419 00270 ∂04-Apr-89 1309 CL-Cleanup-mailer Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS
C01421 00271 ∂04-Apr-89 1309 CL-Cleanup-mailer Issue: TYPE-OF-UNDERCONSTRAINED
C01423 00272 ∂04-Apr-89 1324 CL-Cleanup-mailer issue DYNAMIC-EXTENT-FUNCTION, version 1
C01430 00273 ∂04-Apr-89 1531 CL-Cleanup-mailer Issue: COPY-SYMBOL-PRINT-NAME (not COPY-SYMBOL-COPY-PRINT-NAME)
C01432 00274 ∂04-Apr-89 2058 CL-Cleanup-mailer issue DYNAMIC-EXTENT-FUNCTION, version 1
C01438 00275 ∂05-Apr-89 0710 CL-Cleanup-mailer Re: issue DYNAMIC-EXTENT-FUNCTION, version 1
C01442 00276 ∂05-Apr-89 0721 CL-Cleanup-mailer Re: issue DYNAMIC-EXTENT-FUNCTION, version 1
C01445 00277 ∂05-Apr-89 0805 CL-Cleanup-mailer Re: Issue: LISP-SYMBOL-REDEFINITION
C01447 00278 ∂05-Apr-89 0848 CL-Cleanup-mailer issue DYNAMIC-EXTENT-FUNCTION, version 1
C01449 00279 ∂05-Apr-89 1159 CL-Cleanup-mailer Issue: DYNAMIC-EXTENT (Version 4)
C01468 00280 ∂05-Apr-89 1206 CL-Cleanup-mailer Issue: DYNAMIC-EXTENT (Version 4)
C01470 00281 ∂05-Apr-89 1731 CL-Cleanup-mailer issue DYNAMIC-EXTENT-FUNCTION, version 1
C01473 00282 ∂05-Apr-89 2203 CL-Cleanup-mailer issue DYNAMIC-EXTENT-FUNCTION, version 1
C01476 00283 ∂06-Apr-89 1115 CL-Cleanup-mailer Condensed summary of CL Cleanup meeting results
C01491 00284 ∂09-Apr-89 0921 CL-Cleanup-mailer Issue COMPLEX-RATIONAL-RESULT, version 2
C01499 00285 ∂09-Apr-89 2155 CL-Cleanup-mailer Issue: LISP-SYMBOL-REDEFINITION, v.6
C01508 00286 ∂09-Apr-89 2239 CL-Cleanup-mailer Re: Issue: PACKAGE-FUNCTION-CONSISTENCY
C01510 00287 ∂09-Apr-89 2248 CL-Cleanup-mailer Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
C01512 00288 ∂09-Apr-89 2315 CL-Cleanup-mailer Re: PRETTY-PRINT-INTERFACE, version 4
C01514 00289 ∂09-Apr-89 2332 CL-Cleanup-mailer Issue: READ-DELIMITED-LIST-EOF
C01518 00290 ∂10-Apr-89 0006 CL-Cleanup-mailer Re: Issue: TYPE-OF-UNDERCONSTRAINED
C01520 00291 ∂10-Apr-89 0028 CL-Cleanup-mailer Cleanup Issue status, 10-Apr-89
C01555 00292 ∂10-Apr-89 1025 CL-Cleanup-mailer Cleanup Issue status, 10-Apr-89
C01590 00293 ∂10-Apr-89 1303 CL-Cleanup-mailer Issue: LOAD-TRUENAME (Version 3)
C01601 00294 ∂10-Apr-89 1349 CL-Cleanup-mailer Issue: LOAD-TRUENAME (Version 3)
C01604 00295 ∂10-Apr-89 1621 CL-Cleanup-mailer Issue: PATHNAME-CANONICAL-TYPE
C01613 00296 ∂11-Apr-89 0714 CL-Cleanup-mailer Issue: LOAD-TRUENAME (Version 4)
C01625 00297 ∂11-Apr-89 2155 CL-Cleanup-mailer Re: Issue: PATHNAME-CANONICAL-TYPE
C01629 00298 ∂12-Apr-89 1012 CL-Cleanup-mailer issue PRETTY-PRINT-INTERFACE
C01632 00299 ∂14-Apr-89 0700 CL-Cleanup-mailer Status of CL Condition Handling
C01642 00300 ∂17-Apr-89 1301 CL-Cleanup-mailer [Robert S. Boyer <boyer@CLI.COM>: Fast IO]
C01648 00301 ∂19-Apr-89 0707 CL-Cleanup-mailer [Robert S. Boyer <boyer@CLI.COM>: Fast IO]
C01651 00302 ∂19-Apr-89 1519 CL-Cleanup-mailer no :in-file
C01653 00303 ∂19-Apr-89 1528 CL-Cleanup-mailer [Robert S. Boyer <boyer@CLI.COM>: Fast IO]
C01656 00304 ∂19-Apr-89 1557 CL-Cleanup-mailer no :in-file
C01658 00305 ∂19-Apr-89 1621 CL-Cleanup-mailer no :in-file
C01661 00306 ∂20-Apr-89 1454 CL-Cleanup-mailer Issue: THE-VALUES [was: intent of (THE <type> <expression>)]
C01664 00307 ∂20-Apr-89 2003 CL-Cleanup-mailer Issue: ERROR-TERMINOLOGY (final amended version ??? Version 9)
C01669 00308 ∂24-Apr-89 1249 CL-Cleanup-mailer Issue COMPLEX-RATIONAL-RESULT, version 2
C01672 00309 ∂28-Apr-89 0944 CL-Cleanup-mailer Issue COMPLEX-RATIONAL-RESULT, version 3
C01681 00310 ∂28-Apr-89 1426 CL-Cleanup-mailer ISSUE: GCD-LCM-ZERO-ARGS
C01686 00311 ∂28-Apr-89 1606 CL-Cleanup-mailer Issue: MULTIPLICATION-ZERO-ARGS
C01695 00312 ∂03-May-89 1653 CL-Cleanup-mailer [chapman%aitg.DEC@decwrl.dec.com: question @ SUBTYPEP-TOO-VAGUE]
C01698 00313 ∂04-May-89 0922 CL-Cleanup-mailer Issue: SETF-MULTIPLE-STORE-VARIABLE
C01702 00314 ∂04-May-89 1244 CL-Cleanup-mailer [chapman%aitg.DEC@decwrl.dec.com: question @ SUBTYPEP-TOO-VAGUE]
C01715 00315 ∂04-May-89 1251 CL-Cleanup-mailer Issue: SETF-MULTIPLE-STORE-VARIABLE
C01718 00316 ∂23-May-89 1013 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-CASE (version 4)
C01733 00317 ∂23-May-89 1014 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-VALUE (version 2)
C01749 00318 ∂23-May-89 1015 CL-Cleanup-mailer Issue: PATHNAME-LOGICAL (version 2)
C01774 00319 ∂23-May-89 1017 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (version 6)
C01796 00320 ∂23-May-89 1018 CL-Cleanup-mailer Issue: PATHNAME-WILD (version 5)
C01818 00321 ∂23-May-89 1148 CL-Cleanup-mailer Issue: DATA-IO (version 6)
C01834 00322 ∂23-May-89 1148 CL-Cleanup-mailer Issue: STRING-COERCION (version 2)
C01841 00323 ∂23-May-89 1148 CL-Cleanup-mailer Issue: BIT-ARRAY-FUNCTIONS (version 5)
C01859 00324 ∂23-May-89 1148 CL-Cleanup-mailer Issue: PATHNAME-SYSTEM-TYPE (version 1)
C01866 00325 ∂23-May-89 1228 CL-Cleanup-mailer Issue: STREAM-CAPABILITIES (version 3)
C01873 00326 ∂23-May-89 1231 CL-Cleanup-mailer Issue: MAP-INTO (version 1)
C01879 00327 ∂23-May-89 1231 CL-Cleanup-mailer Issue: FLOAT-UNDERFLOW (version 2)
C01889 00328 ∂24-May-89 0810 CL-Cleanup-mailer Issue: STREAM-CAPABILITIES (version 3)
C01891 00329 ∂24-May-89 0816 CL-Cleanup-mailer Issue: FLOAT-UNDERFLOW (version 2)
C01894 00330 ∂24-May-89 1013 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-CASE (version 4)
C01896 00331 ∂24-May-89 1024 CL-Cleanup-mailer Re: Issue: DATA-IO (version 6)
C01898 00332 ∂24-May-89 1112 CL-Cleanup-mailer Re: Issue: PATHNAME-LOGICAL (version 2)
C01901 00333 ∂24-May-89 1115 CL-Cleanup-mailer Issue: FLOAT-UNDERFLOW (version 2)
C01905 00334 ∂24-May-89 1117 CL-Cleanup-mailer Issue: STREAM-CAPABILITIES (version 3), or Issue: MAP-INTO (version 1)
C01908 00335 ∂24-May-89 1118 CL-Cleanup-mailer Issue: STREAM-CAPABILITIES
C01913 00336 ∂24-May-89 1334 CL-Cleanup-mailer Re: Issue: PATHNAME-LOGICAL (version 2)
C01920 00337 ∂24-May-89 2338 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (version 4)
C01922 00338 ∂24-May-89 2338 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-VALUE (version 2)
C01924 00339 ∂25-May-89 1108 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (version 4)
C01931 00340 ∂25-May-89 1130 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-VALUE (version 2)
C01934 00341 ∂25-May-89 1239 CL-Cleanup-mailer Re: Issue: PATHNAME-LOGICAL (version 2)
C01939 00342 ∂25-May-89 1245 CL-Cleanup-mailer Re: Issue: PATHNAME-SYSTEM-TYPE (version 1)
C01941 00343 ∂25-May-89 1249 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-VALUE (version 2)
C01943 00344 ∂25-May-89 1249 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (version 4)
C01955 00345 ∂25-May-89 1251 CL-Cleanup-mailer Re: Issue: PATHNAME-SUBDIRECTORY-LIST (version 6)
C01957 00346 ∂25-May-89 1258 CL-Cleanup-mailer Issue: FLOAT-UNDERFLOW (version 2)
C01967 00347 ∂25-May-89 1303 CL-Cleanup-mailer Issue: STREAM-CAPABILITIES (version 3), or Issue: MAP-INTO (version 1)
C01969 00348 ∂25-May-89 1306 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (version 6)
C01972 00349 ∂25-May-89 1306 CL-Cleanup-mailer Re: Issue: PATHNAME-WILD (version 5)
C01975 00350 ∂25-May-89 1343 CL-Cleanup-mailer Issue: FLOAT-UNDERFLOW (version 2)
C01980 00351 ∂25-May-89 1350 CL-Cleanup-mailer Re: Issue: PATHNAME-SYSTEM-TYPE (version 1)
C01983 00352 ∂25-May-89 1438 CL-Cleanup-mailer Re: Issue: PATHNAME-SYSTEM-TYPE (version 1)
C01989 00353 ∂25-May-89 1458 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-VALUE (version 2)
C01991 00354 ∂25-May-89 1504 CL-Cleanup-mailer Re: Issue: PATHNAME-SYSTEM-TYPE (version 1)
C01996 00355 ∂25-May-89 1524 CL-Cleanup-mailer Re: Issue: PATHNAME-SYSTEM-TYPE (version 1)
C01999 00356 ∂25-May-89 1557 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (version 4)
C02004 00357 ∂26-May-89 0842 CL-Cleanup-mailer Re: issue DYNAMIC-EXTENT-FUNCTION, version 1
C02007 00358 ∂26-May-89 0907 CL-Cleanup-mailer Issue: PATHNAME-LOGICAL (version 2)
C02017 00359 ∂26-May-89 0917 CL-Cleanup-mailer Re: issue DYNAMIC-EXTENT-FUNCTION, version 1
C02024 00360 ∂26-May-89 0958 CL-Cleanup-mailer Re: Issue: PATHNAME-LOGICAL (version 2)
C02032 00361 ∂26-May-89 1002 CL-Cleanup-mailer Re: issue DYNAMIC-EXTENT-FUNCTION, version 1
C02037 00362 ∂25-May-89 1249 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (version 4), PATHNAME-COMPONENT-VALUE (version 2)
C02040 00363 ∂27-May-89 1552 CL-Cleanup-mailer PARSE-BODY
C02045 00364 ∂29-May-89 1311 CL-Cleanup-mailer Re: Issue: PATHNAME-SYSTEM-TYPE (version 1)
C02049 00365 ∂30-May-89 0544 CL-Cleanup-mailer PARSE-BODY
C02055 00366 ∂30-May-89 0907 CL-Cleanup-mailer Re: Issue: PATHNAME-LOGICAL (version 2)
C02057 00367 ∂04-Jun-89 1215 CL-Cleanup-mailer Re: minor point about extract-declarations
C02063 00368 ∂05-Jun-89 1447 CL-Cleanup-mailer minor point about extract-declarations
C02065 00369 ∂08-Jun-89 1721 CL-Cleanup-mailer Re: Issue: PATHNAME-WILD (version 5)
C02070 00370 ∂08-Jun-89 1723 CL-Cleanup-mailer Re: Issue: PATHNAME-LOGICAL (version 2)
C02076 00371 ∂08-Jun-89 1723 CL-Cleanup-mailer Re: Issue: PATHNAME-LOGICAL (version 2)
C02080 00372 ∂11-Jun-89 1226 CL-Cleanup-mailer issue DYNAMIC-EXTENT-FUNCTION, version 2
C02089 00373 ∂12-Jun-89 1130 CL-Cleanup-mailer issue DYNAMIC-EXTENT-FUNCTION, version 2
C02091 00374 ∂12-Jun-89 1522 CL-Cleanup-mailer Re: Issue: PATHNAME-WILD (version 5)
C02098 00375 ∂12-Jun-89 1601 CL-Cleanup-mailer Issue: PATHNAME-LOGICAL (version 2)
C02124 00376 ∂12-Jun-89 1619 CL-Cleanup-mailer Re: Issue: PATHNAME-WILD (version 5)
C02127 00377 ∂12-Jun-89 1922 CL-Cleanup-mailer Re: Issue: PATHNAME-LOGICAL (version 2)
C02137 00378 ∂13-Jun-89 0755 CL-Cleanup-mailer Re: Issue: PATHNAME-WILD (version 5)
C02140 00379 ∂13-Jun-89 0906 CL-Cleanup-mailer Re: Issue: PATHNAME-WILD (version 5)
C02142 00380 ∂13-Jun-89 0936 CL-Cleanup-mailer Re: Issue: PATHNAME-WILD (version 5)
C02146 00381 ∂13-Jun-89 1148 CL-Cleanup-mailer Re: Issue: PATHNAME-WILD (version 5)
C02156 00382 ∂13-Jun-89 1155 CL-Cleanup-mailer Re: Issue: PATHNAME-LOGICAL (version 2)
C02162 00383 ∂13-Jun-89 1255 CL-Cleanup-mailer Re: Issue: PATHNAME-WILD (version 5)
C02166 00384 ∂13-Jun-89 1315 CL-Cleanup-mailer Re: Issue: PATHNAME-WILD (version 5)
C02168 00385 ∂13-Jun-89 1516 CL-Cleanup-mailer Issue: BIT-ARRAY-FUNCTIONS (Version 5)
C02171 00386 ∂13-Jun-89 1517 CL-Cleanup-mailer Issue: DATA-IO (Version 6)
C02173 00387 ∂13-Jun-89 1518 CL-Cleanup-mailer Issue: FLOAT-UNDERFLOW (Version 2)
C02175 00388 ∂13-Jun-89 1519 CL-Cleanup-mailer Issue: MAP-INTO (Version 1)
C02178 00389 ∂13-Jun-89 1520 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-CASE (Version 4)
C02180 00390 ∂13-Jun-89 1520 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-VALUE (Version 2)
C02182 00391 ∂13-Jun-89 1523 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 6)
C02185 00392 ∂13-Jun-89 1525 CL-Cleanup-mailer Issue: PATHNAME-LOGICAL (Version 2)
C02194 00393 ∂13-Jun-89 1526 CL-Cleanup-mailer Issue: STRING-COERCION (Version 2)
C02196 00394 ∂13-Jun-89 1528 CL-Cleanup-mailer General pathname comments
C02202 00395 ∂13-Jun-89 1528 CL-Cleanup-mailer Issue: PATHNAME-SYSTEM-TYPE (Version 1)
C02204 00396 ∂13-Jun-89 1533 CL-Cleanup-mailer Issue: PATHNAME-WILD (Version 5)
C02206 00397 ∂13-Jun-89 1533 CL-Cleanup-mailer Issue: STREAM-CAPABILITIES (Version 3)
C02208 00398 ∂13-Jun-89 1553 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
C02227 00399 ∂13-Jun-89 1623 CL-Cleanup-mailer General pathname comments
C02235 00400 ∂14-Jun-89 1205 CL-Cleanup-mailer Re: Issue: PATHNAME-LOGICAL (Version 2)
C02241 00401 ∂14-Jun-89 1444 CL-Cleanup-mailer Re: Issue: PATHNAME-SYSTEM-TYPE (Version 1)
C02243 00402 ∂16-Jun-89 1207 CL-Cleanup-mailer Issue: READ-CASE-SENSITIVITY (Version 3)
C02262 00403 ∂16-Jun-89 1329 CL-Cleanup-mailer Issue: SEQUENCE-TYPE-LENGTH (version 1)
C02270 00404 ∂16-Jun-89 1335 CL-Cleanup-mailer Issue: SEQUENCE-TYPE-LENGTH (version 1)
C02279 00405 ∂16-Jun-89 1617 CL-Cleanup-mailer Issue: READ-CASE-SENSITIVITY (Version 3)
C02286 00406 ∂16-Jun-89 2049 CL-Cleanup-mailer issue DYNAMIC-EXTENT-FUNCTION, version 2
C02288 00407 ∂16-Jun-89 2122 CL-Cleanup-mailer Issue: PATHNAME-SYSTEM-TYPE (Version 1)
C02291 00408 ∂17-Jun-89 0851 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 3)
C02299 00409 ∂18-Jun-89 1307 CL-Cleanup-mailer Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
C02302 00410 ∂19-Jun-89 0930 CL-Cleanup-mailer Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
C02306 00411 ∂19-Jun-89 1007 CL-Cleanup-mailer mail lossage (and Issue: READ-CASE-SENSITIVITY (Version 3))
C02310 00412 ∂19-Jun-89 1020 CL-Cleanup-mailer Issue: MAP-INTO (version 2)
C02315 00413 ∂19-Jun-89 1021 CL-Cleanup-mailer Re: Issue: DATA-IO (version 7)
C02318 00414 ∂19-Jun-89 1032 CL-Cleanup-mailer Issue: BIT-ARRAY-FUNCTIONS (version 6)
C02320 00415 ∂19-Jun-89 1046 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 3)
C02328 00416 ∂19-Jun-89 1047 CL-Cleanup-mailer Issue: BIT-ARRAY-FUNCTIONS (version 6)
C02331 00417 ∂19-Jun-89 1109 CL-Cleanup-mailer Re: Issue: DATA-IO (version 7)
C02335 00418 ∂19-Jun-89 1255 CL-Cleanup-mailer Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
C02339 00419 ∂19-Jun-89 1313 CL-Cleanup-mailer re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
C02340 00420 ∂19-Jun-89 1349 CL-Cleanup-mailer Re: Issue: DATA-IO (version 7)
C02345 00421 ∂19-Jun-89 1540 CL-Cleanup-mailer Issue: BIT-ARRAY-FUNCTIONS (version 6)
C02349 00422 ∂19-Jun-89 1545 CL-Cleanup-mailer Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
C02354 00423 ∂20-Jun-89 1358 CL-Cleanup-mailer Issue: SEQUENCE-TYPE-LENGTH (version 1)
C02356 00424 ∂20-Jun-89 1943 CL-Cleanup-mailer Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
C02360 00425 ∂20-Jun-89 2123 CL-Cleanup-mailer re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
C02363 00426 ∂20-Jun-89 2347 CL-Cleanup-mailer Rejected mail
C02367 00427 ∂21-Jun-89 0703 CL-Cleanup-mailer Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
C02372 00428 ∂21-Jun-89 1507 CL-Cleanup-mailer Issue: BIT-ARRAY-FUNCTIONS (version 6)
C02377 00429 ∂21-Jun-89 1511 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 3)
C02383 00430 ∂21-Jun-89 1513 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 3)
C02389 00431 ∂21-Jun-89 1548 CL-Cleanup-mailer Issue SUBTYPEP-TOO-VAGUE, version 5
C02391 00432 ∂21-Jun-89 1732 CL-Cleanup-mailer Issue: BIT-ARRAY-FUNCTIONS (version 6)
C02395 00433 ∂21-Jun-89 1835 CL-Cleanup-mailer Issue: PATHNAME-LOGICAL (version 3)
C02400 00434 ∂21-Jun-89 2208 CL-Cleanup-mailer Re: Issue: MAP-INTO (version 2)
C02402 00435 ∂22-Jun-89 1043 CL-Cleanup-mailer Issue: PATHNAME-LOGICAL (version 3)
C02408 00436 ∂22-Jun-89 1131 CL-Cleanup-mailer Issue: READ-CASE-SENSITIVITY (Version 4)
C02425 00437 ∂22-Jun-89 1159 CL-Cleanup-mailer Issue: PATHNAME-LOGICAL (version 3)
C02428 00438 ∂22-Jun-89 1403 CL-Cleanup-mailer Issue: READ-CASE-SENSITIVITY (Version 4)
C02438 00439 ∂23-Jun-89 0550 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 4)
C02444 ENDMK
C⊗;
∂13-Mar-89 1254 CL-Cleanup-mailer amendments to already passed issues
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89 12:54:30 PST
Received: from fafnir.think.com by Think.COM; Mon, 13 Mar 89 15:50:47 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 13 Mar 89 15:52:12 EST
Received: by verdi.think.com; Mon, 13 Mar 89 15:49:01 EST
Date: Mon, 13 Mar 89 15:49:01 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903132049.AA02739@verdi.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: gls@Think.COM, cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Sat, 11 Mar 89 17:50 EST <19890311225011.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: amendments to already passed issues
Date: Sat, 11 Mar 89 17:50 EST
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
...
I'm glad -somebody- is double-checking already passed issues. Also I'm
glad that -you- are.
Thanks for the compliment. Maybe someday I will have atoned for ~:{ ~:↑ ~}.
--Quux
∂13-Mar-89 1352 CL-Cleanup-mailer Issue: LOAD-OBJECTS (Version 3)
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89 13:51:55 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA16534; Mon, 13 Mar 89 11:37:16 PST
Received: from lukasiewicz.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA20771; Mon, 13 Mar 89 11:32:38 PST
Received: by lukasiewicz.sun.com (4.0/SMI-4.0)
id AA00318; Mon, 13 Mar 89 11:35:38 PST
Date: Mon, 13 Mar 89 11:35:38 PST
From: jrose@Sun.COM (John Rose)
Message-Id: <8903131935.AA00318@lukasiewicz.sun.com>
To: sandra%defun@cs.utah.edu
Cc: rpg@lucid.com, CL-Cleanup@sail.stanford.edu, CL-Compiler@sail.stanford.edu,
Common-Lisp-Object-System@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Sat, 11 Mar 89 18:42:56 MST <8903120142.AA00878@defun.utah.edu>
Subject: Issue: LOAD-OBJECTS (Version 3)
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Date: Sat, 11 Mar 89 18:42:56 MST
...
Have two generic functions, not one. The first would get called by
compile-file and it would return a list of components (or whatever)
that are required to reconstruct the object. The compiler would dump
this list of objects in its usual way. The loader would apply the
second generic function to this list to reconstruct the object. It
avoids the nasty syntax you object to, doesn't require functions to be
dumpable, doesn't require any special support for circular constants,
and ought to be real easy to add to the compiler/loader. (You could
essentially convert the constant into a LOAD-TIME-VALUE expression.)
Two objections here:
One is that this scheme cannot support circular constants. Since
LOAD-OBJECTS is not the issue which determines circular constants, it
probably should not force or presuppose a decision against circular
constants.
Supporting circular constants requires two phases of object
construction, one which creates at least a valid reference to the
object, and a second one which further initializes the object (at least
by patching in back-references to finish building circularities).
In order for your technique to support circular constants, you still
need #'make-load-form to return two things, not one. It would return
two argument lists, and there would be two load-time generic functions.
The other objection is that an arglist for a fixed generic function is
less general and more complex than an EVAL-able form (or a thunk, as rpg
suggests). The programmer must coordinate the construction of the
argument list with the definition of the method to digest it at load
time, which is probably on a different page of the source code. What's
the advantage to offset the complexity and lack of flexibility?
Perhaps method combination within the load-time generic gives a clean
way to modularize the construction of an object of multiple classes?
Someone will have to show me an example of this before I believe it.
Until then, I think the simplicity of thunks (either EVAL-able or
FUNCALL-able) is far preferable.
By the way, I also share rpg's preference for functions over forms,
because functions are parametrized naturally via captured lexicals,
whereas you've got to use backquote to parametrize forms, a more
error-prone technique.
Here's an example which suggests the relative conciseness of the techniques:
;; Using functions:
(defmethod make-load-form ((x myclass))
(let ((p <pval>) (q <qval>) (r <rval>))
#'(lambda () <code>)))
;; Using forms:
(defmethod make-load-form ((x myclass))
`(let ((p ',<pval>) (q ',<qval>) (r ',<rval>))
<code>))
;; Using a generic:
(defmethod make-load-form ((x myclass))
`(cookie00012 :p ,<pval> :q ,<qval> :r ,<rval>))
(defmethod load-time-constructor
((lf (eql 'cookie00012)) &key p q r &allow-other-keys)
<code>)
-Sandra
-------
-- John
∂13-Mar-89 1448 CL-Cleanup-mailer Issue: LOAD-TRUENAME (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Mar 89 14:48:09 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556116; Mon 13-Mar-89 17:45:37 EST
Date: Mon, 13 Mar 89 17:45 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TRUENAME (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890313174517.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
This one was kind of on the table (due to Touretzky), but never got
written up formally. I think it's important, so I'll risk getting yelled
at by sending it out `new' at the last minute...
-----
Issue: LOAD-TRUENAME
Forum: Cleanup
References: LOAD (p426), PROVIDE (p188), REQUIRE (p188),
Issue REQUIRE-PATHNAME-DEFAULTS
Category: ADDITION
Edit history: 13-Mar-89, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
It is difficult to construct sets of software modules which work
together as a unit and which port between different implementations.
REQUIRE and PROVIDE were intended to provide this level of support
but have `failed' to be portable in practice.
Typical user configurations involve a `system definition' file which
loads the modules of a `system' (collection of software modules).
Among the specific problems which arise are:
- File system types may vary. Different file syntax must be used for
each site.
- Even with the same Lisp implementation and host file system type,
the directory in which a software system resides may differ from
delivery site to delivery site.
- Multiple `copies' of the same system may reside in different
directories on the same machine.
Proposal (LOAD-TRUENAME:NEW-PATHNAME-VARIABLES):
Introduce new variables:
*LOAD-TRUENAME* [Variable]
This special variable is initially NIL, but is bound by LOAD to
hold the truename of the pathname of the file being loaded.
*COMPILE-FILE-TRUENAME* [Variable]
This special variable is initially NIL, but is bound by
COMPILE-FILE to hold the truename of the pathname of the file
being compiled.
Example:
------ File SETUP ------
(IN-PACKAGE 'MY-STUFF)
(DEFMACRO COMPILE-TRUENAME () `',*COMPILE-FILE-TRUENAME*)
(DEFVAR *SOURCE-FILE* (COMPILE-TRUENAME) "Just for debugging.")
(DEFVAR *LOADED-FILE* *LOAD-TRUENAME*)
(DEFUN LOAD-MY-SYSTEM ()
(DOLIST (MODULE-NAME '("FOO" "BAR" "BAZ"))
(LOAD (MERGE-PATHNAMES MODULE-NAME *LOAD-TRUENAME*))))
------------------------
(LOAD "SETUP")
(LOAD-MY-SYSTEM)
Rationale:
This satisfies the most common instances of the frequently reported
problem in the Problem Description.
Current Practice:
Wide variation.
In some implementations, calling LOAD binds or sets
*DEFAULT-PATHNAME-DEFAULTS* so that pathnames named in a file being
LOADed will default to being `nearby.'
Some implementations provide special variables that are similar or
identical to one or both of those proposed.
Some implementations have a way to represent the pathname for the
current working directory, and make the default pathname default
to that, so that loading without specifying a default again tends to
get `nearby' files.
None of these techniques is portable, unfortunately, because there
is no agreement.
Cost to Implementors:
Very small.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Continued difficulty for anyone trying to put a system of modules
in a form where they can be conveniently delivered using portable code.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
Negligible.
Discussion:
Touretzky raised the issue most recently on Common-Lisp. A number
of people immediately jumped on the bandwagon, indicating it was
important to them, too.
Pitman made three suggestions in response, of which the above is
the first. The others included:
2. Variables *LOAD-TRUENAMES* and *COMPILE-FILE-TRUENAMES* which hold
lists of the truenames of all files being loaded or compiled,
respectively, during the dynamic invocation of LOAD and COMPILE-FILE.
3. Variable *LOAD-OR-COMPILE-FILE-TRUENAMES* which holds a list like
((LOAD truename) (COMPILE-FILE truename) ...)
during the dynamic invocation of LOAD and COMPILE-FILE.
Touretzky responded:
``I like KMP's proposals. I like the second one best: have separate
variables for files being loaded and files being compiled, and use
them to maintain a stack so we can see the nesting of loads within
files.''
Pitman ultimately chose to present the first rather than the second
because it seemed simpler, easier to explain, and more likely to
pass at this late date.
∂13-Mar-89 1457 CL-Cleanup-mailer Issue CLOS-CONDITIONS, v4
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89 14:57:13 PST
Date: Sat 11 Mar 89 19:32:37-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: Issue CLOS-CONDITIONS, v4
To: kmp@SCRC-STONY-BROOK.ARPA
cc: cl-cleanup@SAIL.STANFORD.EDU, iim%ECLA@ECLC.USC.EDU
Message-ID: <12477306674.30.IIM@ECLA.USC.EDU>
I would like to second Richard Mlynarik's suggestion of a REPORT-CONDITION
method, for much the same reasons he mentioned. It's really ugly to have to
always include the check for *PRINT-ESCAPE* with a CALL-NEXT-METHOD every time
you want to define your own report method for a condition.
kab
-------
∂13-Mar-89 1457 CL-Cleanup-mailer gls cleanups
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89 14:57:49 PST
Date: Sun 12 Mar 89 16:03:32-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: gls cleanups
To: gls@THINK.COM
cc: cl-cleanup@SAIL.STANFORD.EDU, iim%ECLA@ECLC.USC.EDU
Message-ID: <12477530754.30.IIM@ECLA.USC.EDU>
> (2) SYMBOL-MACROLET-SEMANTICS should perhaps also specify that PSETQ of a
> symbol-macro symbol behaves like PSETF.
This probably isn't strictly necessary. PSETQ is a macro which presumably
expands into code which uses SETQ (assuming it doesn't expand into code which
uses an implementation-specific special form), which will then be transformed
into SETF. MULTIPLE-VALUE-SETQ is similar. Of course, it might be easier for
a compiler to optimize a PSETF than the transformed PSETQ expansion.
kab
-------
∂13-Mar-89 1500 CL-Cleanup-mailer Issue ERROR-CHECKING-IN-NUMBERS-CHAPTER
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:00:48 PST
Date: Sun 12 Mar 89 16:01:13-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: Issue ERROR-CHECKING-IN-NUMBERS-CHAPTER
To: kmp@SCRC-STONY-BROOK.ARPA
cc: cl-cleanup@SAIL.STANFORD.EDU, iim%ECLA@ECLC.USC.EDU
Message-ID: <12477530332.30.IIM@ECLA.USC.EDU>
The question of whether NaNs and such cause TYPE-ERROR or ARITHMETIC-ERROR is
what I feel unsure about. We currently signal ARITHMETIC-ERROR, but I don't
believe there was a lot of analysis that went into that decision. I think
that any decision we make on this is likely to be pretty arbitrary. I can't
think of any strong first-principled arguments either way, so it may be a
matter of which seems more convenient to the people who really care about
an error being signaled for such things.
kab
-------
∂13-Mar-89 1501 CL-Cleanup-mailer Issue SUBTYPEP-TOO-VAGUE
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:01:01 PST
Date: Sun 12 Mar 89 16:05:04-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: Issue SUBTYPEP-TOO-VAGUE
To: cl-cleanup@SAIL.STANFORD.EDU
cc: iim%ECLA@ECLC.USC.EDU
Message-ID: <12477531034.30.IIM@ECLA.USC.EDU>
> I don't see any problem here. My compiler has a type testing function
> that handles VALUES types itself and converts (FUNCTION ...) to just
> FUNCTION before calling SUBTYPEP, so it isn't prevented from doing anything
> that it wants.
And what does it do with a deftype'ed type which expands into a list form
FUNCTION type specifier or into a VALUES type specifier? Did you remember to
call type-expand before doing the conversion? Note that a user wouldn't be
able to do that, since type-expand isn't part of the language. And what about
an OR of several FUNCTION or VALUES type specifiers? Besides, it's wrong to
have to define the handling of the VALUES type yourself, even ignoring these
problems, since you end up with each user who wants this capability having to
write his own, rather than having the facility built into SUBTYPEP where it
belongs.
> If you want these cases to be permitted, then you will need to define what
> they mean.
Thats an ugly job. One of us was working on it, but hasn't had much time to
devote to the problem -- probably nobody here at IIM will be able to get to
it any time soon. Right now we mostly just don't want these to be required
signal error cases, with the intention of fully specifying them later.
(Note: some of the ugliness involves questions about what to do when the
typed lambda-lists aren't congruent (in the CLOS sense)).
kab
-------
∂13-Mar-89 1502 CL-Cleanup-mailer Issue PEEK-CHAR-READ-CHAR-ECHO
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:01:49 PST
Date: Sun 12 Mar 89 16:09:23-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: Issue PEEK-CHAR-READ-CHAR-ECHO
To: kmp@SCRC-STONY-BROOK.ARPA
cc: cl-cleanup@SAIL.STANFORD.EDU, iim%ECLA@ECLC.USC.EDU
Message-ID: <12477531820.30.IIM@ECLA.USC.EDU>
The whole discussion of operating system considerations in the proposal just
confuses the issue, and isn't relevent to what the actual proposal says, so
that's a problem with the proposal. It may have lead some people to vote for
it because they got confused into thinking that the operating system
considerations were relevent. Note that I may have fallen into this trap.
When I wrote the example, I was thinking in terms of a reader that used
read-char/unread-char, rather than peek-char. Looking at the proposal again,
I note that it mentions the reader.
However, I think the discussion of the cost of this proposal is pretty weak.
First, an implication of the proposal is that peek-char is no longer
equivelent to read-char followed by unread-char. This means that all code
which uses read-char/unread-char needs to be re-examined, and probably
modified. That's a potentially large amount of code, due to the performance
effect that is not mentioned at all in the proposal. Namely, it is frequently
the case when parsing input that you get stretches where all the characters
are going to be used.
An example might be a reader's subroutine for reading an extended token. If
the two forms of 'peeking' are equivelent, then the token reader can iterate
on read-char until it finds a terminator, unreads it, and proceeds. Under
this proposal, it has to iterate on peek-char, decide if it likes it, and if
so then read-char to really get it. For such important subroutines in the
reader as the token reader, the string reader, the whitespace scanner, and
similar functions, this could mean something on the order of a factor of 2
performance hit. Slowing down important parts of the reader by a factor of
2 is not likely to make anyone smile (except those C lovers out there :-).
We're not advocating that it be left vague. I should have taken the time to
present our counter-proposal, but I was in a hurry, and I've had this note on
my desk to do something about this issue for over a month now, so I didn't.
Foolish me.
Our position is that LAST-READ-CHAR is the proper behavior, with an additional
restriction that it is an error to do output to a stream between the calls to
read and unread. As a hint, here is how we've implemented this behavior.
1. Define two operations on streams, ECHO and UNECHO.
2. echo-streams, when reading a character, apply echo to the output stream and
the character. unread on echo-streams calls unecho on the output stream
and char, in addition to passing along the unread to the input stream.
3. Other meta-streams simply pass these operations along to their output side.
4. data-streams have two choices, depending on whether they have the
capability to 'back out' output. If they can back it out, then echo is
equivilent to write-char, and unecho backs it out. If they can't, then
they record the echo in a slot, writing any already pending echo. unecho
clears the pending echo slot. all normal output operations first write
pending echo. a normal close also forces pending echoing.
There is potentially more hair involved, intended to either support or
complain about improper usage, like calling unread after peek, doing output
between the read and the unread, &etc. Note that this depends on the single
unread restriction in order to work right in all cases.
kab
-------
∂13-Mar-89 1457 CL-Compiler-mailer Issue LOCALLY-TOP-LEVEL, v1
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89 14:57:25 PST
Date: Sat 11 Mar 89 19:34:07-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: Issue LOCALLY-TOP-LEVEL, v1
To: Moon@SCRC-STONY-BROOK.ARPA
cc: cl-cleanup@SAIL.STANFORD.EDU, cl-compiler@SAIL.STANFORD.EDU,
iim%ECLA@ECLC.USC.EDU
Message-ID: <12477306947.30.IIM@ECLA.USC.EDU>
This issue arguably ought to be a compiler issue, rather than cleanup, since
the compiler people seem to be the ones currently mucking about with what we
mean by top-level. (Besides, Larry is overworked as it is :-)
More seriously, I support this idea, in part because of the frob example. This
kind of thing was one of the reasons I voted against the DECLARATION-SCOPE
proposals.
By the way, my notes from the Hawaii meeting say that we passed the NO-HOISTING
proposal, and that LIMITED-HOISTING was not even called to a vote.
kab
-------
∂13-Mar-89 1557 CL-Cleanup-mailer Issue LOCALLY-TOP-LEVEL, v1
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:55:08 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556199; Mon 13-Mar-89 18:51:17 EST
Date: Mon, 13 Mar 89 18:51 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue LOCALLY-TOP-LEVEL, v1
To: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU, cl-compiler@SAIL.STANFORD.EDU
In-Reply-To: <12477306947.30.IIM@ECLA.USC.EDU>
Message-ID: <19890313235118.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sat 11 Mar 89 19:34:07-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
This issue arguably ought to be a compiler issue, rather than cleanup, since
the compiler people seem to be the ones currently mucking about with what we
mean by top-level. (Besides, Larry is overworked as it is :-)
I may have sent it to the wrong committee by mistake. If either Sandra or
Larry instructs me to send it to the other committee, I'll do so forthwith.
More seriously, I support this idea, in part because of the frob example. This
kind of thing was one of the reasons I voted against the DECLARATION-SCOPE
proposals.
By the way, my notes from the Hawaii meeting say that we passed the NO-HOISTING
proposal, and that LIMITED-HOISTING was not even called to a vote.
You're right, I copied down the wrong proposal name. What I said about
it is true of the NO-HOISTING proposal but false of the LIMITED-HOISTING
proposal. This needs to be fixed before it's distributed more widely.
∂13-Mar-89 1726 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89 17:26:13 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 13 MAR 89 17:14:49 PST
Date: 13 Mar 89 17:14 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue PROCLAIM-LEXICAL (Version 9)
In-reply-to: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>'s
message of Mon, 13 Feb 89 20:34:53 GMT
To: cl-cleanup@sail.stanford.edu
Message-ID: <890313-171449-21261@Xerox>
I'm finally getting back to doing some cleanup work, after a long hiatus.
The last version of PROCLAIM-LEXICAL I have is Version 9, which was
distributed before the Hawaii meeting. There were the various comments on
Version 9, amendments proposed but not passed, and, more recently, mail
from Sandra Loosemore, Jeff Dalton, JonL White, Gail Zacharias and David
Moon.
However, there's no new version.
Who will produce one? If we don't have a new version, we probably won't be
able to vote on anything.
I think that would be a shame.
Larry
∂13-Mar-89 1737 CL-Compiler-mailer Re: Issue: LOAD-OBJECTS (Version 3)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 13 Mar 89 17:36:36 PST
Received: by ti.com id AA04345; Mon, 13 Mar 89 19:33:22 CST
Received: from Kelvin by tilde id AA09130; Mon, 13 Mar 89 19:25:26 CST
Message-Id: <2814830669-4406064@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 13 Mar 89 19:24:29 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: "Richard P. Gabriel" <rpg@lucid.com>
Cc: CL-Cleanup@sail.stanford.edu, CL-Compiler@sail.stanford.edu
Subject: Re: Issue: LOAD-OBJECTS (Version 3)
In-Reply-To: Msg of Sat, 11 Mar 89 16:46:51 PST from Richard P. Gabriel <rpg@lucid.com>
> I was a little surprised to see that this proposal talks about load
> forms instead of load functions (which goes to show how much I've been
> paying attention).
One advantage of sticking with the load form approach is that it has
already been implemented and demonstrated to work.
> I think people will find the macro approach (the current approach)
> baroque, partly because the approach is best understood by thinking of
> an input phase to a compiler or some such program, rather than by
> thinking about an output phase when everything has already been supposedly
> created. For example, when I read the current proposal, I imagined it
> in the FASDUMP phase.
Think of it as input to the loader.
> One drawback of my proposal is that the function approach is a little
> more verbose in some cases. I also think it is subject to more
> circularity errors by novices than the macro approach. On the other
> hand, the functional approach makes one think about the issues a
> little harder when writing the code, which is possibly a good thing.
This sounds like a clear disadvantage, without a clear advantage.
> ;; Example 3 (expanded to do a hairy thing that cannot be easily done
> ;; in the macro approach).
...
> One can imagine the shared lexical environment of the creator and initializer
> being a high-bandwidth channel for information, such as the important
> information passed in the above example.
This example illustrates the following assumptions about dumping
constants:
1. Lexical closures can be dumped and loaded.
2. Two closures that share the same environment at compile-time will
also share the same environment at load time.
3. The lexical environment as reconstructed by the loader is not
write-protected (meaning that closures are not really constants).
4. It is safe to assume that none of the closed-over variables are
changed between the time the first closure is dumped and the time
the last closure that shares that environment is dumped.
It could be argued that all of these would be desirable, but I think
it's a little late to be biting off that much.
∂13-Mar-89 1754 CL-Compiler-mailer Re: Issue: LOAD-OBJECTS (Version 3)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 13 Mar 89 17:54:05 PST
Received: by ti.com id AA04437; Mon, 13 Mar 89 19:49:49 CST
Received: from Kelvin by tilde id AA09309; Mon, 13 Mar 89 19:36:34 CST
Message-Id: <2814831335-4446073@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 13 Mar 89 19:35:35 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: jrose@Sun.COM (John Rose)
Cc: sandra%defun@cs.utah.edu, rpg@lucid.com, CL-Cleanup@sail.stanford.edu,
CL-Compiler@sail.stanford.edu
Subject: Re: Issue: LOAD-OBJECTS (Version 3)
In-Reply-To: Msg of Mon, 13 Mar 89 11:35:38 PST from jrose@Sun.COM (John Rose)
> One is that this scheme cannot support circular constants.
I second the objection.
> By the way, I also share rpg's preference for functions over forms,
> because functions are parametrized naturally via captured lexicals,
> whereas you've got to use backquote to parametrize forms, a more
> error-prone technique.
>
> Here's an example which suggests the relative conciseness of the techniques:
>
> ;; Using functions:
> (defmethod make-load-form ((x myclass))
> (let ((p <pval>) (q <qval>) (r <rval>))
> #'(lambda () <code>)))
>
> ;; Using forms:
> (defmethod make-load-form ((x myclass))
> `(let ((p ',<pval>) (q ',<qval>) (r ',<rval>))
> <code>))
I don't think that's a completely fair comparison because the LET is
required for the function approach, but would usually not be needed with
the forms approach:
;; Using functions:
(defmethod make-load-form ((x myclass))
(let ((p <pval>) (q <qval>) (r <rval>))
#'(lambda () (make-mine p q r))))
;; Using forms:
(defmethod make-load-form ((x myclass))
`(make-mine ',<pval> ',<qval> ',<rval>))
This is a very simple use of back-quote, while the function approach is
error-prone because it would be too easy to forget to do the LET
binding.
∂14-Mar-89 0738 CL-Cleanup-mailer Re: Issue PEEK-CHAR-READ-CHAR-ECHO
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 14 Mar 89 07:38:43 PST
Received: from relay2.cs.net by RELAY.CS.NET id ac25715; 14 Mar 89 10:16 EST
Received: from draper.com by RELAY.CS.NET id af09120; 14 Mar 89 10:11 EST
Date: Tue, 14 Mar 89 08:19 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Issue PEEK-CHAR-READ-CHAR-ECHO
To: cl-cleanup@SAIL.STANFORD.EDU
X-VMS-To: CL-CLEANUP,SEB1525
> From: "Kim A. Barrett" <IIM%ECLA@eclc.usc.EDU>
> Subject: Issue PEEK-CHAR-READ-CHAR-ECHO
> To: kmp@scrc-stony-brook.ARPA
> Cc: cl-cleanup@sail.stanford.EDU, iim%ECLA@eclc.usc.EDU
> 1. Define two operations on streams, ECHO and UNECHO.
> 2. echo-streams, when reading a character, apply echo to the output stream and
> the character. unread on echo-streams calls unecho on the output stream
> and char, in addition to passing along the unread to the input stream.
> 3. Other meta-streams simply pass these operations along to their output side.
> 4. data-streams have two choices, depending on whether they have the
> capability to 'back out' output. If they can back it out, then echo is
> equivilent to write-char, and unecho backs it out. If they can't, then
> they record the echo in a slot, writing any already pending echo. unecho
> clears the pending echo slot. all normal output operations first write
> pending echo. a normal close also forces pending echoing.
> There is potentially more hair involved, intended to either support or
> complain about improper usage, like calling unread after peek, doing output
> between the read and the unread, &etc. Note that this depends on the single
> unread restriction in order to work right in all cases.
There SURE IS more hair involved. All you're doing is punting the basic
problem down to a lower level. Maybe the stream internally takes the actual
send-the-character-to-the-output-stream and implements it via SEND-OUT and
UN-SEND-OUT calls, where SEND-OUT buffers the character in case an UN-SEND-OUT
comes along...
In the
'foo(* a b)
example, when the ( is seen, either it gets echoed at that point or it
doesn't. This ECHO/UNECHO stuff doesn't change anything. And posing a
restriction on stream output between READ and UNREAD is unreasonable,
in my opinion.
∂14-Mar-89 0738 CL-Cleanup-mailer More re: PEEK-CHAR-READ-CHAR-ECHO
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 14 Mar 89 07:38:47 PST
Received: from relay2.cs.net by RELAY.CS.NET id ad25718; 14 Mar 89 10:16 EST
Received: from draper.com by RELAY.CS.NET id ag09120; 14 Mar 89 10:12 EST
Date: Tue, 14 Mar 89 08:22 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: More re: PEEK-CHAR-READ-CHAR-ECHO
To: cl-cleanup@SAIL.STANFORD.EDU
X-VMS-To: CL-CLEANUP,SEB1525
Just for the record, I wouldn't wish to see any proposal adopted that didn't
support the notion of PEEK-CHAR being equivalent to READ-CHAR + UNREAD-CHAR.
Maybe the IIM implementation solves this problem - or thinks it does - but
I don't see quite how.
∂14-Mar-89 0756 CL-Cleanup-mailer Re: Issue: DESTRUCTURING-BIND (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 07:56:43 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 07:48:32 PST
Date: 14 Mar 89 07:48 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DESTRUCTURING-BIND (Version 2)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Wed, 25 Jan 89 11:38 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890314-074832-22564@Xerox>
Version 2 is the most recent I have. There's been some debate about &WHOLE,
&ENVIRONMENT, NIL and IGNORE in the destructuring list.
&ENVIRONMENT:
everybody says disallow
&WHOLE:
Moon said allow (the second time.)
NIL:
Moon says allow as a way of ignoring.
KMP says OK.
&BODY:
KMP makes case for disallowing, but says
allow.
There was some additional discussion that resulted in the related issue of
DEFMACRO-LAMBDA-LIST.
I'd be happy with a proposal that said NIL is ignored, &WHOLE and &BODY are
allowed, and that &ENVIRONMENT is disallowed.
KMP made a reference to "the next version" in his message of 30 Jan 89, so
maybe he'll produce one.
Larry
∂14-Mar-89 0835 CL-Cleanup-mailer Re: Issue: CONDITION-RESTARTS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 08:35:34 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 08:28:15 PST
Date: 14 Mar 89 08:27 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: CONDITION-RESTARTS (Version 1)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Sat, 11 Mar 89 22:03 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>,
CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890314-082815-22614@Xerox>
I don't think there will be any strong objection if, after some
consideration, you want to remove a function from the condition system,
even though it is "incompatible"; the condition system has not been with us
long enough that "tweaks" are out of line.
Should the condition system symbols be in the LISP package or the
CONDITIONS package? The current draft of the standard doesn't distinguish
their package.
∂14-Mar-89 0923 CL-Cleanup-mailer More re: PEEK-CHAR-READ-CHAR-ECHO
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 09:23:21 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556600; Tue 14-Mar-89 12:11:10 EST
Date: Tue, 14 Mar 89 12:11 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: More re: PEEK-CHAR-READ-CHAR-ECHO
To: "Steve Bacher (Batchman)" <SEB1525@draper.com>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: The message of 14 Mar 89 08:22 EST from "Steve Bacher (Batchman)" <SEB1525@draper.com>
Message-ID: <19890314171109.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 14 Mar 89 08:22 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Just for the record, I wouldn't wish to see any proposal adopted that didn't
support the notion of PEEK-CHAR being equivalent to READ-CHAR + UNREAD-CHAR.
Such a proposal was already adopted in January by an 11 to 5 vote. To clarify
the double negatives, PEEK-CHAR-READ-CHAR-ECHO as adopted in January eliminates
the equivalence of PEEK-CHAR to READ-CHAR+UNREAD-CHAR, but only when peeking
from a stream created by MAKE-ECHO-STREAM.
We can reconsider anything, of course, if that's how we want to spend our time.
∂14-Mar-89 1104 CL-Cleanup-mailer Re: Issue IGNORE-VARIABLE, v1
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 11:02:36 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 09:41:14 PST
Date: 14 Mar 89 09:03 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue IGNORE-VARIABLE, v1
In-reply-to: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>'s message of Sun, 19
Feb 89 15:42:05 PST
To: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <890314-094114-1073@Xerox>
I didn't check the references when this was first proposed, but presumably
pp 55-56 and 59-65 of CLtL have some indication that duplicates are not
allowed. This issue was "withdrawn", i.e., we didn't propose it.
----- Begin Forwarded Messages -----
Date: Mon, 7 Mar 88 15:06 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LAMBDA-LIST-DUPLICATES (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Issue: LAMBDA-LIST-DUPLICATES
References: 5.1.2 Variables (pp55-56)
5.2.2 Lambda-Expressions (pp59-65),
LET* (p111-112), PROG* (pp131-132)
Category: ADDITION
Edit history: 07-Mar-88, Version 1 by Pitman
Related Issues: DECLARATION-SCOPE
Status: For Internal Discussion
Problem Description:
CLtL forbids binding the same variable more than once in the same
binding form. This rule is claimed by some to be overly restrictive
because there are some well-defined situations in which it would be
useful to duplicate a variable name in the same binding list.
Proposal (LAMBDA-LIST-DUPLICATES:ALLOW-SEQUENTIAL-NON-ITERATIVE):
Allow variable names to be repeated in situations where bindings are
sequential and the binding construct is non-iterative (specifically,
in the &AUX part of a normal lambda list, in the bindings of LET*, and
in the bindings of PROG*).
Test Case:
((LAMBDA (B &AUX (B (+ B 1)) (B (+ B 1))) B) 0) => 2
(LET* ((B 0) (B (+ B 1))) B) => 1
(PROG* ((B 0) (B (+ B 1))) (RETURN B)) => 1
Rationale:
Because these bindings are inherently sequential and non-iterative, there
would no ambiguity about the intended scope bindings, and it is sometimes
useful to repeat the name of a binding when doing various kinds of
encapsulations or successive refinements to the same value.
The intent of duplicated bindings in "parallel binding" constructs like
LET or iterative constructs like DO* is less easy to predict, so it is
not proposed that the current rule be relaxed for such constructs.
Current Practice:
The Symbolics implementation currently checks for this case and
signals an error.
[Others?]
Cost to Implementors:
Converting would be relatively easy, but not completely trivial.
There is some interaction with declaration processing which becomes
involved, too (see issue DECLARATION-SCOPE).
Cost to Users:
None. This is an upward-compatible change.
Cost of Non-Adoption:
Some useful expressional style would be lost.
Benefits:
A useful expressional style would be made available.
Aesthetics:
The rule for variable duplication would be more syntactically complex
but pragmatically simpler.
Discussion:
A request for a discussion of this issue came from the Japanese
community.
Pitman drafted this formal proposal and supports
LAMBDA-LIST-DUPLICATES:ALLOW-SEQUENTIAL-NON-ITERATIVE.
----- Next Message -----
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Tue, 8 Mar 88 20:28:54 gmt
To: CL-Cleanup@sail.stanford.edu
Subject: Issue: LAMBDA-LIST-DUPLICATES (Version 1)
Cc: KMP@scrc-stony-brook.arpa
Current practice:
Both PopLog Common Lisp and KCL allow variables to appear more
than once in a lambda-list. In the three suggested test cases,
they both have the later binding current in the body of the form
and so return the values 2, 1, and 1 respectively.
In addition, both allow variables in other cases, specifically:
KCL:
((lambda (a a) a) 1 2) => 2
PopLog:
((lambda (a a) a) 1 2) => 1
----- Next Message -----
Date: Fri, 11 Mar 88 13:43 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LAMBDA-LIST-DUPLICATES (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880307150614.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I oppose LAMBDA-LIST-DUPLICATES:ALLOW-SEQUENTIAL-NON-ITERATIVE; I think
Common Lisp should continue to forbid binding the same variable more
than once in the same binding form. I have two reasons:
1. This is an unnecessary complication of the language rules. Allowing
duplicated variable names doesn't make it possible to write programs
that you couldn't write before, it just allows the programs to be
written in a more obscure way.
2. This would result in an unnecessary complication of the scoping rules
for DECLARE. Common Lisp would have to define what happens when a
DECLARE of a variable is attached to a form that binds more than one
variable with the declared name.
----- End Forwarded Messages -----
∂14-Mar-89 1253 CL-Cleanup-mailer re: PATHNAME-PRINT-READ, v1
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 12:53:02 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 12:33:37 PST
Date: 14 Mar 89 12:32 PST
From: masinter.pa@Xerox.COM
Subject: re: PATHNAME-PRINT-READ, v1
In-reply-to: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>'s message of Thu, 9 Feb
89 11:25:54 PST
To: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <890314-123337-1569@Xerox>
If this is going to be discussed at the X3j13 meeting, we should have
a new version with all of the various additions to current practice
and discussions appended.
pierson says:
KCL uses #"..."
EB says:
"For Current Practice:
Lucid CL also implements the proposed behavior.
For Cost to Users:
Users who define their own #P read macro may be unhappy.
I weakly support this change.
..."
Masinter says:
"For Current Practice, Envos Medley prints pathnames with the syntax #.(pathname "asdf").
I like #P"asdf" better, but #.(pathname string) is currently pretty portable.
"
Barrett says:
"For Current Practice, IIM Common Lisp prints pathnames with the syntax
#.(parse-namestring "asdf" "host"). The reason for using this convention is
that for some strings you need to know what parsing conventions to use in order
to get back an equivalent pathname. And yes, I agree it is ugly and verbose.
"
KMP and kab sent a long messages but I can't summarize easily.
Mly says "I still don't understand why this needs to be standardised upon..."
and "Even if others do feel an urgent need to allow such portablability, I
don't understand why #S(PATHNAME ...) syntax isn't acceptable."
∂14-Mar-89 1317 CL-Cleanup-mailer Re: PATHNAME-PRINT-READ, v1
Received: from multimax.encore.com ([129.91.1.14]) by SAIL.Stanford.EDU with TCP; 14 Mar 89 13:17:08 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA18290; Tue, 14 Mar 89 16:16:11 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA05011; Tue, 14 Mar 89 16:13:03 EST
Message-Id: <8903142113.AA05011@mist.>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Re: PATHNAME-PRINT-READ, v1
In-Reply-To: Your message of 14 Mar 89 12:32:00 -0800.
<890314-123337-1569@Xerox>
Date: Tue, 14 Mar 89 16:13:01 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Date: 14 Mar 89 12:32 PST
From: masinter.pa@Xerox.COM
If this is going to be discussed at the X3j13 meeting, we should have
a new version with all of the various additions to current practice
and discussions appended.
pierson says:
KCL uses #"..."
Absolutely true. However I don't approve of it for several reasons:
#P is more prevalent
Issue: PRETTY-PRINT-INTERFACE puts #"..." to a better use. This
is relevant for those of us who will use Water's pretty printer
whether or not the issue passes.
#"..." is just too good a "name" to be reserved for pathname syntax.
∂14-Mar-89 1344 CL-Cleanup-mailer Re: Issue: LOAD-TRUENAME (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 13:43:51 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 13:19:26 PST
Date: Tue, 14 Mar 89 13:19 PST
From: Gregor.pa@Xerox.COM
Subject: Re: Issue: LOAD-TRUENAME (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest
In-Reply-To: <890313174517.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890314211919.6.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no
I favor this. I would even favor either of the other two ideas even at
this `late date'. The behavior of each of the proposals is simple, its
easy to see what it will and won't do, and it satisfies a real demand.
I should note that I have never wanted the incremented functionally
offered by the `stack' proposals, but I could still vote for them.
-------
∂14-Mar-89 1344 CL-Cleanup-mailer Re: Issue: CLOS-CONDITIONS (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 13:43:59 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 13:23:23 PST
Date: Tue, 14 Mar 89 13:23 PST
From: Gregor.pa@Xerox.COM
Subject: Re: Issue: CLOS-CONDITIONS (Version 4)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Mly@AI.AI.MIT.EDU, CL-Cleanup@SAIL.Stanford.EDU
Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest
In-Reply-To: <890313130600.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890314212317.7.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no
Date: Mon, 13 Mar 89 13:06 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
I do not agree that it is a -necessary- thing to specify the Meta-Class
of conditions because all intended uses of conditions can be done
without this information.
I don't agree with this. If we don't specify the metaclass, then users
won't know what other classes they can mix in when defining condition
classes. It may seem weird, but I can imagine someone wanting to mix
in an arbitrary class into a condition class.
I think we should just say that the class CONDITION is an instance of
STANDARD-CLASS, and that by default DEFINE-CONDITION defines standard
classes. Sure it might be nice to do the read only class thing but I
don't think this is a good time to design a special purpose metaclass
for this.
-------
∂14-Mar-89 1344 CL-Cleanup-mailer Issue: LOAD-TRUENAME (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 13:44:43 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 556807; 14 Mar 89 16:42:03 EST
Date: Tue, 14 Mar 89 16:42 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TRUENAME (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890313174517.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890314214204.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor LOAD-TRUENAME:NEW-PATHNAME-VARIABLES. I think this
proposal would be greatly improved by adding two more variables,
*LOAD-PATHNAME* and *COMPILE-FILE-PATHNAME*, whose values are
the pathname opened by LOAD or COMPILE-FILE, rather than the
truename. The need for these is more obvious if you think
about systems where the pathname cannot be easily reconstructed
from the truename. This includes file systems with symbolic
links and some pathname systems with logical pathnames.
∂14-Mar-89 1358 CL-Cleanup-mailer Issue: TIME-ZONE-NON-INTEGER
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 13:57:52 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556843; Tue 14-Mar-89 16:55:04 EST
Date: Tue, 14 Mar 89 16:55 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TIME-ZONE-NON-INTEGER
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <8903131137.AA05944@decwrl.dec.com>
Message-ID: <19890314215504.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
TIME-ZONE-NON-INTEGER:ALLOW is okay with me.
∂14-Mar-89 1505 CL-Cleanup-mailer Issue: ERROR-NOT-HANDLED (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 15:04:58 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556941; Tue 14-Mar-89 18:02:30 EST
Date: Tue, 14 Mar 89 18:02 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ERROR-NOT-HANDLED (Version 1)
To: cl-cleanup@sail.stanford.edu
cc: X3J13@sail.stanford.edu
In-Reply-To: <890314-140350-1917@Xerox>
Message-ID: <19890314230224.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
ERROR-NOT-HANDLED:PERMIT-TERMINATION is okay with me. I would
also support a proposal to replace "the condition system as currently
described insists that the interactive debugger be entered if a
condition is unhandled" with wording that allowed implementations
to do whatever they want, with perhaps an implementation note that
many implementations prefer an interactive debugger.
∂14-Mar-89 1612 CL-Cleanup-mailer TYPE-OF-UNDERCONSTRAINED, version 4
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 16:11:32 PST
Received: from fafnir.think.com by Think.COM; Tue, 14 Mar 89 16:46:54 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 14 Mar 89 16:48:13 EST
Received: by verdi.think.com; Tue, 14 Mar 89 16:45:02 EST
Date: Tue, 14 Mar 89 16:45:02 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903142145.AA05320@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Cc: gls@Think.COM
Subject: TYPE-OF-UNDERCONSTRAINED, version 4
This is a proposal to amend version 3, passed as amended (to include
RANDOM-STATE) in January 1989 in Kauai.
Version 4 amends version 3 to add SHORT-FLOAT, LONG-FLOAT, and RATIONAL
to the list of types in part (a) of the proposal.
Forum: Cleanup
Issue: TYPE-OF-UNDERCONSTRAINED
References: TYPE-OF (CLtL)
88-002R (Class-of)
88-005, p 43f, Condition system types
Related issues: SUBTYPEP-TOO-VAGUE
DATA-TYPE-HIERARCHY-UNDERSPECIFIED
FUNCTION-TYPE
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
COERCE-INCOMPLETE
Category: CLARIFICATION/CHANGE
Edit history: Version 1, 1-Dec-88, Masinter
Version 2, 9-Dec-88, Masinter
Version 3, 12-Dec-88, Masinter (fix "egregious bug")
Versino 4, 3-14-89 Steele
Problem description:
The specification of TYPE-OF in CLtL is so weak as to leave it
nearly useless, if any implementor actually took the specification
seriously.In particular, there are almost no constraints on the
value that TYPE-OF might return for any of the built in
types. The only constraint placed is that for objects created by the
constructor function of DEFSTRUCT, the result of TYPE-OF is the name of the
defstruct.
This means that implementations could return T for all other objects.
Proposal (TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS):
Specify that the result of TYPE-OF satisfies the following:
(a) For any object for which (typep object built-in-type) is true when
built-in-type is one of
INTEGER, RATIO, FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, COMPLEX, NUMBER
SYMBOL,
STRING, VECTOR, ARRAY, RANDOM-STATE
CONS,
STREAM, PACKAGE, CHARACTER, FUNCTION, READTABLE, HASH-TABLE, PATHNAME,
CONDITION, RESTART,
RATIONAL, SHORT-FLOAT, LONG-FLOAT
the result of TYPE-OF will be a type specifier for which
(subtypep (type-of object) built-in-type) returns T T, i.e., either the
build-in-type or a subtype of it (a subtype that the
implementation's SUBTYPEP can recognize.)
(b) For all objects, (TYPEP object (TYPE-OF object)) will be true.
(this implies that it will not be NIL, since no
object is of type NIL.)
(c) will not be a MEMBER type specifier, or T.
For objects created by the "constructor" function of a structure
defined with DEFSTRUCT without a :TYPE option, TYPE-OF
will return the structure name.
For objects created by MAKE-INSTANCE, giving a named
class, TYPE-OF will return the class name of the class.
For objects which are instances of anonymous classes (i.e., where
(CLASS-NAME (CLASS-OF object)) is NIL), the result of TYPE-OF should be the
class object itself.
(The CLOS specification has already specified that class objects are
acceptable wherever type specifiers are, and in particular, as input to
SUBTYPEP and TYPEP.)
This proposal is intended to be consistent with 88-002R,
and not to conflict with any of the definitions in that document.
Examples:
It is legal for (TYPE-OF "abc") to return (SIMPLE-STRING 3), or just
STRING. It is legal for (TYPE-OF 112312) to return SI:MEDIUM-SIZE-FIXNUM,
as long as (SUBTYPEP 'SI:MEDIUM-SIZE-FIXNUM 'INTEGER).
Given:
(defvar *foo* (make-array 5 :element-type t))
(class-name (class-of *foo*)) => SIMPLE-VECTOR
It is legal for
(type-of *foo*) => (SIMPLE-VECTOR 5)
Rationale:
The original specification for "TYPE-OF" was written to allow
implementation freedom, but the wording is in fact more vague than was
intended.
Current practice:
Most Common Lisp implementations seem to implement the proposal, at least
for the types we've tried them on.
Cost to Implementors:
Even if there are implementations that do not currently implement the
proposal, the required changes for them are likely to be minimal.
Cost to Users:
Apparently none.
Cost of non-adoption:
TYPE-OF would remain potentially inconsistent.
Performance impact:
Likely none.
Benefits:
Bring the specification of TYPE-OF in like with its common
implementation, while requiring it to be generally useful.
Esthetics:
Little effect.
Discussion:
Originally, TYPE-OF was concieved as being useful for information display.
CLOS specified CLASS-OF far more precisely, in that it must return exactly
the class of an object. Unless TYPE-OF is removed from the language, it
seems reasonable to require it to be at least as precise as CLASS-OF.
The accepted CLOS specification does not define CLASS-OF
in terms of TYPE-OF, but an earlier draft did.
This proposal presumes the (passed) proposals
DATA-TYPES-HIERARCHY-UNDERSPECIFIED:DISJOINT, FUNCTION-TYPE, and
accomodates the Condition System (version 18) and CLOS.
If ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS does not pass,
and this proposal does pass, it may be that the only way an
implementation can satisfy (TYPEP array (TYPE-OF array))
would be to have (TYPE-OF array) return VECTOR or ARRAY
as appropriate, i.e., with no element type qualification.
It is possible to constrain TYPE-OF further, e.g., to eliminate
the possibility that it might return a non-portable
implementation-specific value. For example,
(TYPE-OF 112312) should not return SI:MEDIUM-SIZE-FIXNUM, but rather some
thing like (SIGNED-BYTE 17) [if that's what SI:MEDIUM-SIZE-FIXNUM means.]
We would like to make this as an implementation recommendation,
however, rather than as a constraint, at this point.
∂14-Mar-89 1613 CL-Cleanup-mailer SYMBOL-MACROLET-SEMANTICS, version 6
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 16:12:48 PST
Received: from fafnir.think.com by Think.COM; Tue, 14 Mar 89 16:42:18 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 14 Mar 89 16:43:40 EST
Received: by verdi.think.com; Tue, 14 Mar 89 16:40:28 EST
Date: Tue, 14 Mar 89 16:40:28 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903142140.AA05308@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Cc: gls@Think.COM
Subject: SYMBOL-MACROLET-SEMANTICS, version 6
This is a proposal to amend version 5, passed in January 1989 in Kauai.
Version 6 amends version 5 to require PSETQ to behave like PSETF,
to require MULTIPLE-VALUE-SETQ to accept symbol macros (but not
general SETF places), and to specify the interaction with the
*MACROEXPAND-HOOK* function.
Issue: SYMBOL-MACROLET-SEMANTICS
References: SYMBOL-MACROLET (88-002R page 2-81)
Related Issues: SYMBOL-MACROLET-DECLARE
Category: CHANGE
Edit history: 29-July-88, Version 1 by Piazza
21-September-88, Version 2 by Piazza
22-September-88, Version 3 by Piazza
22-September-88, Version 4 by Piazza
30-Nov-88, Version 5 by Masinter
14-Mar-89, Version 6 by Steele
Problem Description:
The SYMBOL-MACROLET construct, introduced with CLOS in X3J13 document
88-002R, profoundly alters the interpretation of symbols appearing as
forms in a Common Lisp program--what previously was necessarily a variable
might now be a symbol macro instead. Macros which appear in the body of a
SYMBOL-MACROLET form are currently unable to determine whether a symbol
form is a variable or a symbol macro, and, if the latter, what the
expansion of the symbol macro is. Consequently, complex macros (such as
SETF or PUSH) which depend on the form of their argument(s), are unable to
produce their desired results in some cases, as in the following example:
(let ((a (make-array 5))
(i 0))
(symbol-macrolet ((place (aref a (incf i))))
(push x place))
i) ==> 2
In addition, it would be both natural and nice to be able to write
(with-slots (rho theta) point
(declare (single-float rho theta))
...computation...)
as well as DECLARE within SYMBOL-MACROLET forms.
Proposal (SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM):
Change the definition of SYMBOL-MACROLET to specify that it is a special
form, which affects the evaluation environment for symbols. Enhance
MACROEXPAND and MACROEXPAND-1 so that they can expand a symbol macro.
Modify SETF et al to use the new MACROEXPAND and MACROEXPAND-1 to examine
even symbol subforms. Specify that the expansion of a symbol macro IS
subject to further macro expansion in the same lexical environment as the
symbol macro invocation, exactly analogous to normal macros. Clarify that
within the body of a SYMBOL-MACROLET, SETQ of a symbol defined as
a symbol macro will be treated as if it were a SETF.
Furthermore PSETQ of a symbol defined as a symbol macro will
behave as if it were a PSETF, and MULTIPLE-VALUE-SETQ will behave
as if SETQ were used on each variable to be set.
When MACROEXPAND or MACROEXPAND-1 sees a symbol macro, it calls
the value of *MACROEXPAND-HOOK* in the same manner as for an
ordinary macro. The three values given to the hook function
in this case will be an expansion function, a form (in this case
the symbol naming the symbol macro), and an environment. The
only guaranteed property of the expansion function is that when
it is applied to the form and the environment it will return the
correct expansion of the symbol macro. (In particular, nothing
it said in this specification whether the expansion is conceptually
stored in the expansion function, the environment, or both.)
Rationale:
The potential for interaction between macros is exactly why &environment
arguments were originally added to macros. Changing SYMBOL-MACROLET to be
a special form, which communicates through the &environment arguments to
macros with MACROEXPAND and MACROEXPAND-1, would allow PUSH and SETF
(among others) to work with SYMBOL-MACROLET in the same way they work with
MACROLET.
This change cannot (reasonably) support the currently specified semantics
that the expansion text is "outside" the scope of the symbol macro. For
indeed, when the symbol macro is expanded, (a copy of) the expansion is
then within the scope of the SYMBOL-MACROLET, and should then be subject
to further scrutiny. The issue of "infinite expansion" of symbol macros is
no more dangerous than that of normal macros.
Current Practice:
Portable Common Loops provides a code-walking implementation of
SYMBOL-MACROLET as specified in 88-002R. Symbolics Cloe has both a
code-walking version of a SYMBOL-MACROLET macro and compiler support for
a SYMBOL-MACROLET special form.
Cost to Implementors:
If SYMBOL-MACROLET is modified to be a special form, compilers and
interpreters will have to change, as well as MACROEXPAND, MACROEXPAND-1,
PUSH, INCF, DECF, and others.
Cost to Users:
If SYMBOL-MACROLET is converted to a special form, code-walking programs
will have to be modified to handle SYMBOL-MACROLET correctly. Those same
programs would have to be modified to handle the other special forms
specified in CLOS, anyway.
Cost of Non-Adoption:
SYMBOL-MACROLET will retain its confusing semantics, leading to bugs when
it interacts with complex macros and forms which produce side-effects.
Implementations which support ONCE-ONLY will break. For that matter, any
mechanism which examines code and assumes that "variables" have no side
effects will break.
Benefits:
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM avoids the hairiest problems
surrounding interaction of macros (like SETF) and side effects, and makes
SYMBOL-MACROLET consistent with MACROLET.
Aesthetics:
If SYMBOL-MACROLET is made to be a special form, aesthetics are improved
by making symbol macros consistent with normal macros.
Discussion:
A case could be made for adding a new function, SYMBOL-MACRO-FUNCTION, as
a dual of MACRO-FUNCTION. However, symbol macros are simpler than normal
macros: a symbol macro is associated with a single expansion form, rather
than an arbitrary function which computes the expansion. For this reason,
the augmented MACROEXPAND-1 proposed here can also fill the role of
SYMBOL-MACRO-FUNCTION: the second value of (macroexpand-1 sym env) will be
T if and only if sym is a symbol macro, while the first value gives the
expansion of sym, if it has one.
Rather than extending the existing MACROEXPAND and MACROEXPAND-1
functions, new functions could be introduced to expand symbol macros.
However, there seems to be no particular reason to do this.
∂14-Mar-89 1731 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:30:51 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 MAR 89 14:18:15 PST
Date: 14 Mar 89 14:17 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 1)
In-reply-to: David N Gray <Gray@DSG.csc.ti.com>'s message of Thu, 9 Mar 89
18:01:27 CST
To: David N Gray <Gray@DSG.csc.ti.com>, Jeff Dalton
<jeff@aiai.edinburgh.ac.uk>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890314-141815-1956@Xerox>
I have 15 replies to version 1, but no version 2.
Personally, I think adding a character translation table is overkill if all
that's wanted is case sensitive or no, and the performance cost unwieldy.
"Gilding the lilly."
Why not just (READTABLE-CASE <readtable>) that accepts/returns :UPCASE (the
default) or :DOWNCASE.
Note that the setting of the READTABLE-CASE in *READTABLE* should affect
printing: if (READTABLE-CASE *READTABLE*) is :DOWNCASE, then *PRINT-CASE*
is ignored; symbols should be printed with the same case as their internal
name.
This is effectively what Medley does; it was necessary to support
readtables with a case sensitive "bit" so that the same environment could
simultaneously support Interlisp (which is case sensitive) and Common Lisp.
If this is going to go anywhere, we'll need a version 2. If you want to
proceed with just the READTABLE-CHARACTER-TRANSLATION, I won't squawk too
loudly (but I think I would vote against all of the proposals, even the one
I outline above, on the grounds that they are 'unnecessary' complications.)
∂14-Mar-89 1731 CL-Cleanup-mailer RE: Cleanup Issue Status
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:31:21 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 MAR 89 15:36:44 PST
Date: 14 Mar 89 15:35 PST
From: masinter.pa@Xerox.COM
Subject: RE: Cleanup Issue Status
In-reply-to: your message of Sun, 19 Feb 89 23:14:37 PST
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890314-153644-2132@Xerox>
I have finally gotten around to reconciling your errata list from my status
list. Our differences are now:
> >+ DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
> >Version 3, 13-Jan-89
> >Status: passed, Jan 89 X3J13
> I believe this one was amended.
-- I have no amendments marked. Do you know what the amendment was?
> >+ DEFSTRUCT-REDEFINITION
> >Synopsis: what happens if you redefine a DEFSTRUCT?
> >Version 3, 6-Feb-89
> >Status: Passed (as amended) Jan 89 X3J13
> I don't have this one marked as amended.
-- Version 3 is the "amended" version, and was distributed after X3J13.
> >- DELETE-FILE-NONEXISTENT
> >Version 1, 5-Oct-88
> >Comments: should just signal different errors?
> >Status: withdrawn
> I marked this as tabled.
-- I know no-one who intends to raise it. Maybe KMP's error signalling
proposal? I'll check.
> >- ELIMINATE-FORCED-CONSING
> >Synopsis: Add :RECYCLE or :MODIFY to some sequence fns,
> >Version 3, 31-Aug-88
> >Status: withdrawn
> I marked this as tabled.
-- No, I think we all thought this was a bad idea after all.
> >- FORMAT-ROUNDING
> >Synopsis: specify that ~F rounds up
> >Version 1, 5-Oct-88
> >Status: withdrawn
> I marked this as tabled.
-- This was your issue originally. JonL said: "However, both Moon and I
seemed to prefer not trying to specify something in the standard for the
case this issue is addressing." and there was no dissent. Do you want to
re-raise it?
> >+ FUNCTION-COMPOSITION
> >Synopsis: Add new functions
> >Version 5, 10-Feb-89
> >Status: Passed (as amended) Jan 89 X3J13
> I know this is picky, but I thought it was decided to fail this one
> completely and amend TEST-NOT-IF-NOT (I believe that was the related
> issue).
-- you may be right. I wish we had minutes. I guess I'll stick by my
summary unless I hear otherwise.
> >+ PEEK-CHAR-READ-CHAR-ECHO
> >Version 3, 8-Oct-88, Released 8 Oct 88
> >Synopsis: PEEK-CHAR, READ-CHAR on streams made by MAKE-ECHO-STREAM
> >Status: Passed, Jan 89 X3J13
> I have this marked as amended.
-- I have no amendments made at the meeting. Do you?
> >- TRACE-ERROR
> >Synopsis: TRACE should signal errors if it doesn't understand
> >Version 1, 20-Jun-88
> >Comments: is this a cleanup?
> >Status: withdrawn
> I marked this as tabled.
-- I don't have anyone willing to bring it up.
∂14-Mar-89 1732 CL-Cleanup-mailer revised: Cleanup Issue Status
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:31:47 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 16:17:29 PST
Date: 14 Mar 89 16:16 PST
From: masinter.pa@Xerox.COM
Subject: revised: Cleanup Issue Status
In-reply-to: your message of Sun, 19 Feb 89 23:14:37 PST
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890314-161729-2231@Xerox>
Ooops... I missed your later note about "amendments" being just "notes".
Our differences are now only over whether things were "tabled" or
"withdrawn" and whether FUNCTION-COMPOSITION was amended or whether it was
rejected with TEST-NOT-IF-NOT amended to include what was left of it:
> >- DELETE-FILE-NONEXISTENT
> >Version 1, 5-Oct-88
> >Comments: should just signal different errors?
> >Status: withdrawn
> I marked this as tabled.
-- I know no-one who intends to raise it. Maybe KMP's error signalling
proposal? I'll check.
> >- ELIMINATE-FORCED-CONSING
> >Synopsis: Add :RECYCLE or :MODIFY to some sequence fns,
> >Version 3, 31-Aug-88
> >Status: withdrawn
> I marked this as tabled.
-- No, I think we all thought this was a bad idea after all.
> >- FORMAT-ROUNDING
> >Synopsis: specify that ~F rounds up
> >Version 1, 5-Oct-88
> >Status: withdrawn
> I marked this as tabled.
-- This was your issue originally. JonL said: "However, both Moon and I
seemed to prefer not trying to specify something in the standard for the
case this issue is addressing." and there was no dissent. Do you want to
re-raise it?
> >+ FUNCTION-COMPOSITION
> >Synopsis: Add new functions
> >Version 5, 10-Feb-89
> >Status: Passed (as amended) Jan 89 X3J13
> I know this is picky, but I thought it was decided to fail this one
> completely and amend TEST-NOT-IF-NOT (I believe that was the related
> issue).
-- you may be right. I wish we had minutes. I guess I'll stick by my
summary unless I hear otherwise.
> >- TRACE-ERROR
> >Synopsis: TRACE should signal errors if it doesn't understand
> >Version 1, 20-Jun-88
> >Comments: is this a cleanup?
> >Status: withdrawn
> I marked this as tabled.
-- I don't have anyone willing to bring it up.
∂14-Mar-89 1732 CL-Cleanup-mailer Issue: PRETTY-PRINT-INTERFACE (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:32:09 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 17:05:00 PST
Date: 14 Mar 89 17:04 PST
From: masinter.pa@Xerox.COM
Subject: Issue: PRETTY-PRINT-INTERFACE (Version 1)
In-reply-to: Guy Steele <gls@Think.COM>'s message of Fri, 24 Feb 89
17:40:25 EST
To: Guy Steele <gls@Think.COM>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890314-170500-2365@Xerox>
Dan Pierson had a few specific comments.
Kim Barrett says
"... The stuff about ~W providing circularity detection, and ~<...~:>
providing
depth abbreviation and circularity detection is wrong. This functionality
should always be provided, and not require the use of special format
directives
to get it. See the recently passed issue PRINT-CIRCLE-STRUCTURE...."
Can we get a new version that addresses those comments?
I think if we email things out by Thursday we might have a chance of
avoiding the "two-weekers".
Thanks,
Larry
∂14-Mar-89 1732 CL-Compiler-mailer Re: Potential issue: MACRO-SPECIAL-FORMS
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:32:00 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 16:49:34 PST
Date: 14 Mar 89 16:48 PST
From: masinter.pa@Xerox.COM
Subject: Re: Potential issue: MACRO-SPECIAL-FORMS
In-reply-to: Gregor.pa's message of Thu, 9 Mar 89 19:14 PST
To: Gregor.pa@Xerox.COM, David A. Moon
<Moon@STONY-BROOK.SCRC.Symbolics.COM>, Jeff Dalton
<jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, Kent M Pitman
<KMP@STONY-BROOK.SCRC.Symbolics.COM>, cl-compiler@sail.stanford.edu,
cl-cleanup@sail.stanford.edu
Message-ID: <890314-164934-2319@Xerox>
a) if anything is going to happen on this at the next meeting, we need a
proposal writeup. This week.
b) I like the proposal (in Jeff's oiginal "potential issue"). I agree that
we might want something stronger -- like extending the list of special
forms to include the ones that a code walker *really* has to know about,
but I don't know if we can reach closure.
c) I'd rather do nothing than do something wrong.
∂14-Mar-89 1743 CL-Cleanup-mailer Issue: FORMAT-PLURALS (not yet submitted)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:43:47 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 MAR 89 17:31:41 PST
Date: 14 Mar 89 17:31 PST
From: masinter.pa@Xerox.COM
Subject: Issue: FORMAT-PLURALS (not yet submitted)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Mon, 6 Mar 89 23:50 EST
To: Dave.Touretzky@cs.cmu.edu
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890314-173141-2452@Xerox>
Is there a chance you could produce a revised version, in "standard"
writeup format in the next day or two? There have been significant
comments since your original message. There seems to be willingness
in cleanup committee to pursue this.
I don't know how much patience you have for our cumbersome procedures,
especially given your 'hit ratio'.
!
Format for proposals to the cleanup committee (Version 14)
October 5, 1988
Replace the text below in >> double inverted angle-brackets <<. Be
brief; leave testimonials and personal opinions to the discussion at the
end. Be complete; do not expect someone else to fix or redesign parts.
Spell out names (e.g., Masinter rather than LMM) and upper-case all Lisp
symbols (DEFUN rather than Defun). I like it better if you write in the
third person rather than first.
Remember that this is a proposal to a change to the standard
for Common Lisp, not recommendations to the editor, not
a set of recommendations to Common Lisp implementors.
Forum: Cleanup
Issue: >>A short descriptive label, which starts with a name
which occurs in the index of CLtL, and be a suitable
symbol in the Common Lisp style, e.g., CDR-TERMINATION.
When in doubt, let the cleanup committee assign the name.
The name should match the problem description, not the
proposal.<<
References: >>The pages of CLtL which describe the feature being
discussed, and other references.<<
Related issues: >> names of other cleanup issues about the same topic.<<
Category: >>One or more of:
CLARIFICATION -- proposal to resolve an ambiguity or case
of under-specified situation in CLtL, where this
ambiguity interferes with portability of code.
CHANGE -- proposal for an incompatible change.
ADDITION -- proposal for a compatible extension<<
Edit history: >>Author and date of submission (version 1), and author
and date of subsequent versions.<<
Problem description:
>>Describe the problem being addressed -- why is the current situation
unclear or unsatisfactory? Avoid describing the proposal here or arguing
for its adoption. <<
Proposal (>>issue-label:proposal-label<<): >> Describe as precisely as
possible what you are proposing. This can take the form of
text that could be dropped into the new specification document.
Proposals should be for changes to Common Lisp, rather than changes to
CLtL. If necessary, propose a set of labelled alternatives here, rather
than a single proposal. Each proposal must be a complete design; do not
leave out details. Avoid arguing for the proposal here, just describe
it.<<
Examples:
>> Examples are samples of Common Lisp code that illustrates the issue.
along with explanatory text. Please explain what the examples should
do, do in current implementations, and any special tricks.<<
Test Cases:
>> Test Cases are simple stand-alone expressions which are valid and
do not signal an error if the proposal is adhered to. (Use ASSERT
if needed.) Omit if you have none.
<<
Rationale:
>> A one or two sentence summary of the arguments that follow. <<
Current practice:
>>Do some/many/no Common Lisp implementations already work this way?
Survey independent Common Lisp implementations - preferably three or
more. What do they do on the test cases or examples? What do current
user programs do? Are there textbooks which describe this feature? <<
Cost to Implementors:
>>What is the cost to implementors of adopting the proposal? How much
implementation effort is required? Is public-domain code available? For
pervasive changes, can the conversion be automated?<<
Cost to Users:
>>For incompatible changes, what is the cost to users of converting
existing user code? To what extent can the process be automated? How?<<
Cost of non-adoption:
>>How serious is it if nothing is done? <<
Performance impact:
>> what does the proposal do to better or worsen the size or speed
of user programs and implementations? <<
Benefits:
>>What is better if the proposal is adopted? How serious is the problem
if just left as it is? <<
Esthetics:
>>How does this proposal affect the simplicity of the language, ease of
learning, etc. You can spell it aesthetics if you like. <<
Discussion:
>> Additional arguments, discussions, endorsements, testimonials, etc.
should go here. Testimonials are the least effective; the discussion should
be useful to someone not already with the issue or those discussing it.
Avoid a blow-by-blow account of debates or recounting of history. <<
∂14-Mar-89 1756 CL-Cleanup-mailer Re: Issue: COPY-SYMBOL-PRINT-NAME (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:55:56 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 MAR 89 17:46:04 PST
Date: 14 Mar 89 17:45 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: COPY-SYMBOL-PRINT-NAME (Version 1)
In-reply-to: chapman%aitg.DEC@decwrl.dec.com's message of 8 Mar 89 08:22
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Message-ID: <890314-174604-2496@Xerox>
Kathy:
Can you update this to say STRING= and summarize the subsequent discussion?
Thanks
Larry
∂14-Mar-89 1812 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
Received: from PORSCHE.SCRC.Symbolics.COM ([128.81.41.69]) by SAIL.Stanford.EDU with TCP; 14 Mar 89 18:11:58 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by PORSCHE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 6566; Tue 14-Mar-89 20:43:54 EST
Date: Tue, 14 Mar 89 20:43 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 1)
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890314-141815-1956@Xerox>
Message-ID: <890314204336.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: 14 Mar 89 14:17 PST
From: masinter.pa@Xerox.COM
Why not just (READTABLE-CASE <readtable>) that accepts/returns :UPCASE (the
default) or :DOWNCASE.
This would be fine, but I would prefer :PRESERVE rather than :DOWNCASE for the
alternate value. One might legitimately want :DOWNCASE as well (although it
would be near useless for CL, it might be useful for other things) so I wouldn't
want to lock down that name.
All in all, though, I like somebody's (Gray's?) suggestion of a function rather
than a table. The default being #'CHAR-UPCASE, and #'IDENTITY being another
obvious choice.
The reason I like the function rather than the keyword is that you don't have
to initially provide the alternate functionality -- user's can add it. In the
case of the keyword, it has to be given by the system so you're at the mercy
of the implementors as to which options you get. I think this feature is worth
the added complexity.
∂15-Mar-89 0542 CL-Cleanup-mailer Issue: COPY-SYMBOL-PRINT-NAME
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 15 Mar 89 05:41:51 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA29246; Wed, 15 Mar 89 05:39:23 PST
Message-Id: <8903151339.AA29246@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for cl-cleanup@sail.stanford.edu; id AA29246; Wed, 15 Mar 89 05:39:23 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 15 Mar 89 08:29
To: cl-cleanup@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: COPY-SYMBOL-PRINT-NAME
!
From: DECWRL::AITG::CHAPMAN "8-Mar-89 0822 GMT" 8-MAR-1989 08:32:30.91
To: cl-cleanup@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
CC:
Subj: Issue: COPY-SYMBOL-PRINT-NAME
Issue: COPY-SYMBOL-PRINT-NAME
References: COPY-SYMBOL (p. 169)
Category: CLARIFICATION
Edit history: 1-MAR-89, Version 1 by Chapman
15-MAR-89, Version 2 by Chapman
Problem Description:
The description of COPY-SYMBOL states that it "returns a new uninterned
symbol with the same print name as sym (its first argument)". The words
"the same as" are not defined in CLtL. Do they mean EQ, EQUAL, ...?
Proposal (COPY-SYMBOL-PRINT-NAME:EQUAL)
The description of COPY-SYMBOL should read as follows:
"COPY-SYMBOL returns an uninterned
symbol whose print name is STRING= to
the print name of the symbol that is the first argument to COPY-SYMBOL."
Suggested implementation note:
The string should not be copied unnecessarily. In this case, the uninterned
symbol's print name would be EQ to the print name of the argument symbol.
Rationale:
This clarification resolves any possibility of ambiguity.
Current Practice:
Medley did this: the symbol names didn't really have a string header and
some symbol names (the "initial symbols" ) had a different place for
storing the actual characters than symbols created later. Unfortunately,
that means that SYMBOL-NAME has to CONS.
It wasn't so much a problem for Interlisp since most of the "string"
functions in Interlisp will take symbols, but in Common Lisp, it is a
performance hit. Poor design, but there's no reason to require SYMBOL-NAME
to return EQ strings.
In this case, the strings aren't EQ even though the string characters are
shared. (Think of it as strings displaced to a shared area.)
Adoption Cost:
?
Benefits:
Less ambiguity in the specification, and potentially more portable code.
Conversion Cost:
?
Aesthetics:
None.
Discussion:
∂15-Mar-89 0549 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 7)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 05:49:48 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAR 89 05:43:34 PST
Date: 15 Mar 89 05:42 PST
From: masinter.pa@Xerox.COM
Subject: Issue: EQUAL-STRUCTURE (Version 7)
To: cl-cleanup@Sail.Stanford.Edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890315-054335-3530@Xerox>
This is what I believe was voted in at the last meeting.
I'm not sure why we started discussing it again, but
I didn't see anything in the discussion that looked like
a proposal to revisit this issue.
!
Status: Passed as amended, Jan 89 X3J13
Issue: EQUAL-STRUCTURE
References: EQUAL (p80), EQUALP (p81)
Category: CLARIFICATION/CHANGE
Edit history: 18-Mar-88, Version 1 by Pitman
08-Jun-88, Version 2 by Masinter (add Benson's proposal)
23-Sep-88, Version 3 by Masinter (remove all but STATUS-QUO)
01-Oct-88, Version 4 by Masinter (fix description)
01-Oct-88, Version 5 by Pitman (correct wording, add discussion)
11-Jan-89, Version 6 by Pitman (attempt EQUALP correction)
15-Mar-89, Version 7 by Masinter (amended as per vote at Jan 89 X3J13)
Problem Description:
The behavior of EQUAL and EQUALP on structures is a subject of controversy.
At issue are whether these functions should descend the slots of structures
or use simply the structure's primitive identity (i.e., EQ) to test for
equivalence.
Proposal (EQUAL-STRUCTURE:MAYBE-STATUS-QUO):
Clarify that EQUAL and EQUALP do not descend any structures or data types
other than the ones explicitly specified in CLtL.
Type EQUAL Behavior EQUALP Behavior
Number uses EQL uses =
Character uses EQL uses CHAR-EQUAL
Cons descends descends
Bit-Vector descends descends
String descends descends
Pathname magic per CLtL same as EQUAL
Structure uses EQ uses EQ
other Array uses EQ descends
Hash-Table uses EQ (see below)
Instance (Standard-Object) uses EQ uses EQ
Other uses EQ uses EQ
Note that the order of this table is in some cases important, with upper
entries taking priority over lower ones.
EQUALP descends hash tables by first comparing the count of entries
and the :TEST function; if those are the same, it compares the
keys of the tables using the :TEST function and then the values
of the matching keys using EQUALP recursively.
Rationale:
There seem to be as many different equality primitives as there
are applications for them. None of the possible ways of changing
EQUAL or EQUALP are flawless. Given the inability to "fix" them,
it is better to leave them alone.
Current Practice:
We are unaware of any extensions to CLtL's set of operations,
although frequently users request them.
Cost to Implementors:
Since this seems to be compatible with the status quo, none.
Cost to Users:
Same
Cost of Non-Adoption:
Ongoing controversy about whether EQUAL and EQUALP "do the right thing".
Benefits:
A feeling that EQUAL and EQUALP exist and/or do what they do because serious
consideration was given and we consciously decided on a particular resolution
to the numerous questions that have come up about them.
Aesthetics:
There seems to be wide debate about what the proper aesthetics for
how equality should work in Common Lisp. While the status quo is not
aesthetically more pleasing than the various alternatives, aesthetic
considerations vary widely. Different people model structures
differently. Sometimes the same person models structures differently in
different situations. The question of which should be descended and which
should not is a very personal one, and the aesthetic attractiveness of any
of these options will vary from person to person or application to
application.
Discussion:
An earlier version of this issue with various alternatives was distributed
at the June 1988 X3J13 meeting. Since
this is a frequently raised issue, we thought we should submit it
as a clarification although there is no change to CLtL.
Options for which we considered proposals were:
- removing EQUAL and EQUALP from the standard.
- changing EQUALP to descend structures.
- changing EQUALP to be case sensitive.
- adding a :TEST keyword to EQUAL.
- making EQUAL a generic function
All of these had some serious problems.
The cleanup committee supports option STATUS-QUO.
It would be useful if descriptions of EQUAL and EQUALP contained some sort
of additional commentary alluding to the complex issues discussed here.
The following is offered to the Editorial staff as a starting point:
Object equality is not a concept for which there is a uniquely
determined correct algorithm. The appropriateness of an equality
predicate can be judged only in the context of the needs of some
particular program. Although these functions take any type of
argument and their names sound very generic, EQUAL and EQUALP are
not appropriate for every application. Any decision to use or not
use them should be determined by what they are documented to do
rather than any abstract characterization of their function. If
neither EQUAL nor EQUALP is found to be appropriate in a particular
situation, programmers are encouraged to create another operator
that is appropriate rather than blame EQUAL or EQUALP for ``doing
the wrong thing.''
!
Additional Comments to Version 6:
Version 6 attempts to fix some of the problems noted in Version 5.
There are still some open questions. Only the "Proposal"
part has been changed since Version 5; some of the costs,
benefits & other discussion is now incorrect.
Kent says:
Please read this very carefully before voting in favor of it.
There were a lot of Yes votes for the last version, which I think
had some serious bugs in it. This would be a very bad issue for
us to screw up.
Things that might need special attention:
- Moon contends that standard practice in Symbolics Lisp is
for instances to be compared using EQ under EQUALP, not by
descending. There may be performance issues involved here.
Some agreement needs to be reached.
- Neither the previous version of the proposal nor CLtL was
clear on what happens to pathnames under EQUALP. This showed
up when I converted the presentation below. That issue should
be addressed as well.
Hopefully if this version of the proposal isn't something you want to
vote yes for, at least it's in a suitable form for easy line-item
changes interactively in the meeting.
----- End Forwarded Messages -----
∂15-Mar-89 0641 CL-Cleanup-mailer Re: Issue: OPTIMIZE-SAFETY (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 06:41:30 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAR 89 06:37:00 PST
Date: 15 Mar 89 06:36 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: OPTIMIZE-SAFETY (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Mon, 6 Mar 89 17:42 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890315-063700-3610@Xerox>
My reading is that this is currently being pursued as an editorial issue
and that it will not appear on the "cleanup" list.
Y'all let me know if you disagree.
∂15-Mar-89 0720 CL-Cleanup-mailer Re: Issue ERROR-CHECKING-IN-NUMBERS-CHAPTER
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 07:19:00 PST
Received: from Semillon.ms by ArpaGateway.ms ; 15 MAR 89 07:03:16 PST
Date: 15 Mar 89 07:02 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue ERROR-CHECKING-IN-NUMBERS-CHAPTER
In-reply-to: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>'s message of Sun, 12
Mar 89 16:01:13 PST
To: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
cc: kmp@symbolics.com, cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <890315-070316-3648@Xerox>
I think NaNs should cause ARITHMETIC-ERROR, since "what's one man's NaN is
another man's number."
To put it another way, TYPE-ERROR is generally a sign of a program error
and the cases in which it is signalled should usually not vary from
implementation to implementation; however, which cases signal
ARITHMETIC-ERROR can vary depending on the implementation's floating number
range.
Should we define specific conditions to correspond to the IEEE conditions
as subtypes of ARITHMETIC-ERROR?
I think that it is important to bring this issue to the X3J13 meeting, even
if it isn't quite ready for vote.
If there's a new draft soon, we can have it available for discussion there,
and maybe get an "endorse in principle".
∂15-Mar-89 0720 CL-Cleanup-mailer
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 07:20:26 PST
Received: from Semillon.ms by ArpaGateway.ms ; 15 MAR 89 07:15:06 PST
Date: 15 Mar 89 07:14 PST
From: masinter.pa@Xerox.COM
To: alarson@src.honeywell.com (Aaron Larson)
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890315-071506-3662@Xerox>
Unfortunately, there is a "nest" of cleanup items on pathnames
that have been postponed. Here's PATHNAME-SUBDIRECTORY-LIST.
----- Begin Forwarded Messages -----
Date: Wed, 28 Dec 88 14:32 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Ok, I've been through and I think successfully merged all the pending
discussion, most of which seemed to center around issues of :UP.
-----
Issue: PATHNAME-SUBDIRECTORY-LIST
References: Pathnames (pp410-413), MAKE-PATHNAME (p416),
PATHNAME-DIRECTORY (p417)
Category: CHANGE
Edit history: 18-Jun-87, Version 1 by Ghenis.pasa@Xerox.COM
05-Jul-88, Version 2 by Pitman (major revision)
28-Dec-88, Version 3 by Pitman (merge discussion)
Status: For Internal Discussion
Related-Issues: PATHNAME-COMPONENT-CASE
Problem Description:
It is impossible to write portable code that can produce a pathname
in a subdirectory of a hierarchical file system. This defeats much of
the purpose of having an abstraction like pathname.
According to CLtL, only a string is a portable filler of the directory
slot, but in order to denote a subdirectory, the use of separators (such
as dots, slashes, or backslashes) would be necessary. The very fact that
such syntax varies from host to host means that although the
representation might be "portable", the code using that representation
is not portable.
This problem is even worse for programs running on machines on a network
that can retrieve files from multiple hosts, each using a different OS
and thus a different subdirectory delimiter.
Related problems:
- In some implementations "FOO.BAR" might denote the "BAR" subdirectory
of "FOO" while in other implementations because "." is not the
separator. To be safe, portable programs must avoid all potential
separators.
- Even in implementations where "." is the separator, "FOO.BAR" may be
recognized by some to mean the "BAR" subdirectory of "FOO" and by others
to mean `a seven letter directory with "." being a superquoted part of
its name'.
- In fact, CLtL does not even say for toplevel directories whether the
directory delimiters are a part. eg, is "foo" or "/foo" the directory
filler for a unix pathname "/foo/bar.lisp". Similarly, is "[FOO]" or
"FOO" the directory filler for a VMS pathname "[FOO]ME.LSP"?
Proposal (PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION)
Allow a list to be a filler of a pathname. The car of the list may be either
of the symbols :ABSOLUTE or :RELATIVE.
If the car of the list is :RELATIVE, the rest of the list is the
implementation-dependent result of PARSE-NAMESTRING for file systems which
have relative pathnames. Unless some other proposal is submitted to clarify
the behavior of relative pathnames in merging, etc. that behavior is left
undefined.
If the car of the list is :ABSOLUTE, the rest of the list is a list of
strings each naming a single level of directory structure. The strings
should contain only the directory names themselves -- no separator
characters.
The spec (:ABSOLUTE) represents the root directory.
Clarify that if a string is used as a filler of a directory field in a
pathname, it should be the unadorned name of a toplevel directory.
Specifying a string, str, is equivalent to specifying the list
(:ABSOLUTE str).
In place of a string, at any point in the list, keyword symbols may occur
to deal with special file notations. The following symbols have standard
meanings; they may not be meaningful for all operating systems, and are
intended for use only on those operating systems where they have meaning:
:WILD - Wildcard match of one level of directory structure.
:WILD-INFERIORS - Wildcard match of any number of directory levels.
:UP - Go upward in directory structure (semantic).
:BACK - Go upward in directory structure (syntactic).
The difference between up and back is that if there is a directory
(:ABSOLUTE "X" "Y" "Z")
linked to
(:ABSOLUTE "A" "B" "C")
and there also exist directories
(:ABSOLUTE "A" "B" "Q")
(:ABSOLUTE "X" "Y" "Q")
then
(:ABSOLUTE "X" "Y" "Z" :OUT "Q")
designates
(:ABSOLUTE "A" "B" "Q")
while
(:ABSOLUTE "X" "Y" "Z" :UP "Q")
designates
(:ABSOLUTE "X" "Y" "Q")
Test Case:
(PATHNAME-DIRECTORY (PARSE-NAMESTRING "[FOO.BAR]BAZ.LSP")) ;on VMS
=> (:ABSOLUTE "FOO" "BAR")
(PATHNAME-DIRECTORY (PARSE-NAMESTRING "/foo/bar/baz.lisp")) ;on Unix
=> (:ABSOLUTE "foo" "bar")
or (:ABSOLUTE "FOO" "BAR")
If PATHNAME-COMPONENT-CASE:CANONICALIZE passes, only the 2nd return value.
(PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>**>bar>baz.lisp")) ;on LispM
=> (:ABSOLUTE "FOO" :WILD-INFERIORS "BAR")
(PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>*>bar>baz.lisp")) ;on LispM
=> (:ABSOLUTE "FOO" :WILD "BAR")
Rationale:
This would allow programs to usefully deal with hierarchical file systems,
which are by far the most common file system type.
Current Practice:
Symbolics Genera implements something very similar to this. The main
differences are:
- In Genera, there is no :ABSOLUTE keyword at the head of the list.
This has been shown to cause some problems in dealing with root
directories. Genera represents the root directory by a keyword
symbol (rather than a list) because the list representation
was not adequately general.
- Genera represents Unix ".." as :UP, but deals with :UP
syntactically, not semantically.
Cost to Implementors:
In principle, nothing about the implementation needs to change except
the treatment of the directory field by MAKE-PATHNAME and
PATHNAME-DIRECTORY. The internal representation can otherwise be left
as-is if necessary.
For implementations that choose to rationalize this representation
throughout their internals and any other implementation-specific
accessors, the cost will be necessarily higher.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Serious portability problems would continue to occur. Programmers would be
driven to the use of implementation-specific facilities because the need
for this is frequently impossible to ignore.
Benefits:
The serious costs of non-adoption would be avoided.
Aesthetics:
This representation of hierarchical pathnames is easy to use and quite
general. Users will probably see this as an improvement in the aesthetics.
Discussion:
This issue was raised a while back but no one was fond of the particular
proposal that was submitted. This is an attempt to revive the issue.
The original proposal, to add a :SUBDIRECTORIES field to a pathname, was
discarded because it imposed an unnatural distinction between a toplevel
directory and its subdirectories. Pitman's guess is the the idea was to
try to make it a compatible change, but since most programmers will
probably want to change from implementation-specific primitives to portable
ones anyway, that's probably not such a big deal. Also, there might have
been some programs which thought the change was compatible and ended up
ignoring important information (the :SUBDIRECTORIES field). Pitman thought
it would be better if people just accepted the cost of an incompatible
change in order to get something really pretty as a result.
This issue used to address the issue of relative pathnames (pathnames
relative to some default which is separately maintained). Pitman removed
this issue for now in order to simplify things. He feels the issue should
be resubmitted under separate cover so that it can be discussed separately.
----- Next Message -----
Date: Thu, 29 Dec 88 13:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <881228143206.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
I approve PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION but note the
following typos and proposed simplifications. Also, don't you need
functions like Symbolics' DIRECTORY-PATHNAME-AS-FILE and
PATHNAME-AS-DIRECTORY? The conversion between the name of a directory
and the directory component of a file inferior to that directory is
system-dependent, for example TOPS-20 appends a type field and Unix does
not. Also in some systems the root directory has a name and in others
it doesn't. Of course these functions signal an error in
non-hierarchical file systems. Should there be a separate proposal for
these?
Typos (and some discussion):
Problem Description:
- In some implementations "FOO.BAR" might denote the "BAR" subdirectory
of "FOO" while in other implementations because "." is not the
separator.
Some words must be missing after "while".
Proposal (PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION)
:UP - Go upward in directory structure (semantic).
:BACK - Go upward in directory structure (syntactic).
The difference between up and back is that if there is a directory
(:ABSOLUTE "X" "Y" "Z")
linked to
(:ABSOLUTE "A" "B" "C")
and there also exist directories
(:ABSOLUTE "A" "B" "Q")
(:ABSOLUTE "X" "Y" "Q")
then
(:ABSOLUTE "X" "Y" "Z" :OUT "Q")
designates
(:ABSOLUTE "A" "B" "Q")
while
(:ABSOLUTE "X" "Y" "Z" :UP "Q")
designates
(:ABSOLUTE "X" "Y" "Q")
Is :OUT a typo for :BACK? Also I don't understand what your proposed
semantic/syntactic distinction is. I almost thought I did until I read
the above text carefully and saw that the syntactic one chases links
to the truename and the semantic one does not, which seems backwards.
I also don't think :UP and :BACK are meaningful anywhere except immediately
after :RELATIVE, although I have to concede that Unix disagrees with me
and therefore Symbolics Genera's Unix pathname support also disagrees
with me. But if they were only allowed immediately after :RELATIVE I
don't think you would need two of them. I also don't think that
MERGE-PATHNAMES should ever look at what files/directories actually
exist in the file system, which makes me opposed to the existence
of the one that you have called syntactic. Is this really something
we need, or will TRUENAME do the job?
I think we should only have :UP and not :BACK.
Current Practice:
- Genera represents Unix ".." as :UP, but deals with :UP
syntactically, not semantically.
After you straighten out the definition of syntactic and semantic, check
whether this statement is true. (I'm always irked by proposals where
the current practice section is wrong, because someone wrote an original
proposal where the current practice section was right, then the group
changed the proposal all around but didn't update the current practice
section).
Discussion:
This issue used to address the issue of relative pathnames (pathnames
relative to some default which is separately maintained). Pitman removed
this issue for now in order to simplify things. He feels the issue should
be resubmitted under separate cover so that it can be discussed separately.
It seems to me that this fully addresses relative pathnames already. The
discussion of :UP and :BACK (if freed of typos) seems specific enough that
even though this proposal doesn't explicitly propose what MERGE-PATHNAMES
does with relative pathnames, I think there is only one thing that it could
do that would be consistent. A pathname with a :RELATIVE directory is
not very different from a pathname with a NIL directory; in either case
you have to merge with a default to find the real directory to use; thus
I don't think there are any other new issues with relative pathnames.
----- Next Message -----
Date: Thu, 29 Dec 88 14:54 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19881229182903.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 29 Dec 88 13:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
... don't you need functions like Symbolics' DIRECTORY-PATHNAME-AS-FILE and
PATHNAME-AS-DIRECTORY? The conversion between the name of a directory
and the directory component of a file inferior to that directory is
system-dependent, for example TOPS-20 appends a type field and Unix does
not. Also in some systems the root directory has a name and in others
it doesn't. Of course these functions signal an error in
non-hierarchical file systems. Should there be a separate proposal for
these? ...
I guess it's enough related to this topic that it could piggy back.
Certainly these functions made no sense prior to this proposal and
now they are suddenly important, so I'll see about putting them in on
next pass.
... Is :OUT a typo for :BACK? ...
Yeah. Sloppy editing. Sorry.
Also I don't understand what your proposed semantic/syntactic
distinction ...
Semantic means you have to probe the file system. Syntactic means
looking at the file names themselves is enough. Maybe I screwed up
the presentation. I'll double-check.
Genera is syntactic in that it doesn't probe when processing :UP.
That means that MERGE-PATHNAMES on
(:ABSOLUTE "X" "Y" "Z")
and
(:RELATIVE :UP "Q")
returns
(:ABSOLUTE "X" "Y" "Q")
rather than
(:ABSOLUTE "X" "Y" "Z" :UP "Q")
If you were going to contract out the :UP, you'd need to probe the
file system to make sure
(:ABSOLUTE "A" "B" "Q")
wasn't more correct than
(:ABSOLUTE "X" "Y" "Q")
so I think Genera has a bug.
I think this because if I do:
cd /m/n/o
cd ../q
on Unix I get one place, but in Genera if I visit a file in the
editor named
/m/n/o/x.lisp
and then I type c-X c-F and when prompted for a filename I type
../q/x.lisp
I end up with
/m/n/o/q/x.lisp
rather than the x.lisp in the directory that Unix itself would have
plopped me in if I'd used the cd commands above.
If you disagree, please reply to me privately so we can avoid
further confusion, quickly iron it out offline, and then report a
joint answer (and rationale) to everyone else once we've achieved
consensus.
I also don't think :UP and :BACK are meaningful anywhere except immediately
after :RELATIVE, although I have to concede that Unix disagrees with me
and therefore Symbolics Genera's Unix pathname support also disagrees
with me.
When I previously raised this topic, there were a pile of messages on
exactly this subject. My putting these into the proposal was an attempt
to address those topics. Even if I took these out, the current proposal
offers the flexibility that implementations could offer them without being
in violation of the spec. On the other hand, if people -are- going to offer
them, we might as well agree on common names if it's possible to do so.
But if they were only allowed immediately after :RELATIVE I
don't think you would need two of them.
I claim my example above refutes this.
I also don't think that
MERGE-PATHNAMES should ever look at what files/directories actually
exist in the file system,
If you permit :UP in absolute pathnames, you don't have to look in the
file system. You just get some funny names. Most file systems that
have this feature permit such funny names, though. eg, /foo/../bar/x
is valid in Unix, I understand. If memory serves me, Multics permits
>foo>bar>baz<x>y in Multics, no? Our (Symbolics) pathname system doesn't
permit embedded "<", but the error message suggests that this is only
because there's no obvious interpretation. We could define it to mean
:BACK rather than :UP, so that syntactic merges could be done and
unique pathnames would always be generated.
which makes me opposed to the existence
of the one that you have called syntactic.
In any case, I'm sympathetic to your desire to not look in the file
system. I just think that if a file system designer has made a
decision that forces you to look in the file system to get the right
answer, I don't know what we the CL designers can do to alter that.
The same issue comes up for logical devices and as Sandra has reminded
us, we've not done a particularly good job of papering over that real
externally-induced issue either.
Is this really something we need, or will TRUENAME do the job?
TRUENAME and OPEN would, presumably, not return pathnames with :UP
references (except maybe in pathological situations which they tell
me you can make in Unix if you try hard enough where the only way to
get to a directory is to go down first and then dig upward.)
I think we should only have :UP and not :BACK.
Nothing forces a file system to have both. The question is whether
there are some file systems that have one set of semantics and others
which have the other. If so, then two tokens are needed. In the discussion
leading up to this, people asserted (and I took them at their word) that
there were such competing semantics.
Current Practice:
- Genera represents Unix ".." as :UP, but deals with :UP
syntactically, not semantically.
After you straighten out the definition of syntactic and semantic, check
whether this statement is true. (I'm always irked by proposals where
the current practice section is wrong, because someone wrote an original
proposal where the current practice section was right, then the group
changed the proposal all around but didn't update the current practice
section).
I'll double-check when I've made the next version.
Discussion:
This issue used to address the issue of relative pathnames (pathnames
relative to some default which is separately maintained). Pitman removed
this issue for now in order to simplify things. He feels the issue should
be resubmitted under separate cover so that it can be discussed separately.
It seems to me that this fully addresses relative pathnames already. The
discussion of :UP and :BACK (if freed of typos) seems specific enough that
even though this proposal doesn't explicitly propose what MERGE-PATHNAMES
does with relative pathnames, I think there is only one thing that it could
do that would be consistent. A pathname with a :RELATIVE directory is
not very different from a pathname with a NIL directory; in either case
you have to merge with a default to find the real directory to use; thus
I don't think there are any other new issues with relative pathnames.
Well, there was the whole treatment of :UP. I hadn't really meant for this
proposal to specify that treatment so much as to identify a common representation
so we'd be a little less divergent in the areas we hadn't really specified.
Does anyone think I should add a disclaimer in the proposal body similar to the
one for :OLDEST, :INSTALLED, etc in pathname versions in CLtL that says that
although these are semi-standard names, there is no attached semantics?
----- Next Message -----
Date: Thu, 29 Dec 88 16:05 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <881229145413.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Thu, 29 Dec 88 14:54 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Date: Thu, 29 Dec 88 13:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Also I don't understand what your proposed semantic/syntactic
distinction ...
Semantic means you have to probe the file system. Syntactic means
looking at the file names themselves is enough. Maybe I screwed up
the presentation. I'll double-check.
OK, I understand, and you did screw up the presentation.
But if they were only allowed immediately after :RELATIVE I
don't think you would need two of them.
I claim my example above refutes this.
Agreed.
I also don't think that
MERGE-PATHNAMES should ever look at what files/directories actually
exist in the file system,
If you permit :UP in absolute pathnames, you don't have to look in the
file system. You just get some funny names. Most file systems that
have this feature permit such funny names, though. eg, /foo/../bar/x
is valid in Unix, I understand. If memory serves me, Multics permits
>foo>bar>baz<x>y in Multics, no?
No. Although that's from memory: there are few Multices left, I don't
have an account of any of them, and my manuals are in the attic at home.
I think you got syntactic and semantic mixed up again. I think you're
saying that MERGE-PATHNAMES of a relative directory against an absolute
directory will remove :UP, since that's purely syntactic, but will leave
:BACK in the middle of the merged directory, since resolving :BACK
"semantically" would require accessing the file system, which
MERGE-PATHNAMES doesn't do. Okay.
These names are extremely confusing, obviously. Can anyone think
of better ones than :UP and :BACK?
Our (Symbolics) pathname system doesn't
permit embedded "<", but the error message suggests that this is only
because there's no obvious interpretation.
The error message I get doesn't suggest anything, it's just "Embedded <?".
We could define it to mean
:BACK rather than :UP, so that syntactic merges could be done and
unique pathnames would always be generated.
I don't understand this sentence. Say it again after we all agree on
which one is :UP and which one is :BACK.
which makes me opposed to the existence
of the one that you have called syntactic.
In any case, I'm sympathetic to your desire to not look in the file
system. I just think that if a file system designer has made a
decision that forces you to look in the file system to get the right
answer, I don't know what we the CL designers can do to alter that.
The same issue comes up for logical devices and as Sandra has reminded
us, we've not done a particularly good job of papering over that real
externally-induced issue either.
Is this really something we need, or will TRUENAME do the job?
TRUENAME and OPEN would, presumably, not return pathnames with :UP
references (except maybe in pathological situations which they tell
me you can make in Unix if you try hard enough where the only way to
get to a directory is to go down first and then dig upward.)
I think we should only have :UP and not :BACK.
Nothing forces a file system to have both. The question is whether
there are some file systems that have one set of semantics and others
which have the other. If so, then two tokens are needed. In the discussion
leading up to this, people asserted (and I took them at their word) that
there were such competing semantics.
I don't know enough about the weird file systems out there to dispute this.
Well, there was the whole treatment of :UP. I hadn't really meant for this
proposal to specify that treatment so much as to identify a common representation
so we'd be a little less divergent in the areas we hadn't really specified.
Does anyone think I should add a disclaimer in the proposal body similar to the
one for :OLDEST, :INSTALLED, etc in pathname versions in CLtL that says that
although these are semi-standard names, there is no attached semantics?
Yes, I think :UP and :OLDEST have the same status, but no I don't agree
that that status is that they have no semantics. I agree with what CLtL
page 412 actually says, which is that either an implementation doesn't
support these keywords or if it does support them they have prescribed
meanings.
----- Next Message -----
Date: Thu, 29 Dec 88 14:48:23 PST
From: Jim McDonald <jlm@lucid.com>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon's message of Thu, 29 Dec 88 13:29 EST
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)
>> Is this really something we need, or will TRUENAME do the job?
If you're trying to create a filename to be used for output, it might
not exist yet (hence TRUENAME would signal an error), but there might
be various funny links in its directory path you would like to
traverse. Presumably you could use PROBE-FILE on some part of the
name (perhaps recursively down through the super-directories), then
merge in the remaining part, but that seems enough error-prone to be
worth hiding.
BTW, I think the labelling of semantic/syntactix examples was reversed
in the proposal, independantly of :UP vs. :BACK.
jlm
----- End Forwarded Messages -----
∂15-Mar-89 0741 CL-Cleanup-mailer Re: Issue: PLUS-ABNORMAL (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 07:41:36 PST
Received: from Semillon.ms by ArpaGateway.ms ; 15 MAR 89 07:33:42 PST
Date: 15 Mar 89 07:33 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PLUS-ABNORMAL (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Wed, 8 Mar 89 14:14 EST
To: CL-Cleanup@SAIL.Stanford.EDU, skona%csilvax@hub.ucsb.edu
Message-ID: <890315-073342-3688@Xerox>
I agree with KMP's "... if we want to do anything with +, ++, etc. it may
be to say that they are reserved for the implementation to assign as it
sees fit, and to give only vague guidelines beyond that -- referring
people to the implementation's manual for specifics."
I'm uncomfortable "pinning" down +, ++ and +++, since they cannot be used
reasonably by any portable code.
The notion of "evaluation" and "aborting" is fairly complex when there are
separate read-eval-print loops, debuggers, etc. For example, it seemed
reasonable to update *, ** once the values had been computed but before
they had been printed, in the case that the printing was aborted. The
"input" variables (-, +, ++, ...) are updated immediately after READ,
however.
In fact, the situation was more complicated because of the addition of
interleaved history lists; the history list itself maintains a corrolated
input-output history in "prompt" order, while there's a global ("last
value") IT that is shared by all Execs. ("Prompt" order is different than
"input" order, since the event number in the history list is allocated at
the time the prompt is generated, rather than when the input is complete.)
At one time I wanted to push for removing +, ++, +++, - from the standard
completely for what might be called 'aesthetic' grounds. I think they are
the only symbols in CL with unrelated value & function interpretations, for
example.
∂15-Mar-89 0817 CL-Cleanup-mailer Cleanup Issue Status
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 08:15:31 PST
Received: from fafnir.think.com by Think.COM; Wed, 15 Mar 89 11:08:57 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 15 Mar 89 11:10:06 EST
Received: by verdi.think.com; Wed, 15 Mar 89 11:06:53 EST
Date: Wed, 15 Mar 89 11:06:53 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903151606.AA01268@verdi.think.com>
To: masinter.pa@xerox.com
Cc: chapman%aitg.DEC@decwrl.dec.com, cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@xerox.com's message of 14 Mar 89 15:35 PST <890314-153644-2132@Xerox>
Subject: Cleanup Issue Status
> >+ FUNCTION-COMPOSITION
> >Synopsis: Add new functions
> >Version 5, 10-Feb-89
> >Status: Passed (as amended) Jan 89 X3J13
> I know this is picky, but I thought it was decided to fail this one
> completely and amend TEST-NOT-IF-NOT (I believe that was the related
> issue).
-- you may be right. I wish we had minutes. I guess I'll stick by my
summary unless I hear otherwise.
My notes show that the COMPLEMENT function was accepted and
all other parts of the proposal failed.
--Guy
∂15-Mar-89 0845 CL-Cleanup-mailer Re: Cleanup Issue Status
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 15 Mar 89 08:45:15 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA23362; Wed, 15 Mar 89 11:42:12 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA05621; Wed, 15 Mar 89 11:40:30 EST
Message-Id: <8903151640.AA05621@mist.>
To: Guy Steele <gls@Think.COM>
Cc: masinter.pa@xerox.com,
"chapman%aitg.DEC@decwrl.dec.com"@multimax.encore.com,
cl-cleanup@sail.stanford.edu
Subject: Re: Cleanup Issue Status
In-Reply-To: Your message of Wed, 15 Mar 89 11:06:53 -0500.
<8903151606.AA01268@verdi.think.com>
Date: Wed, 15 Mar 89 11:40:28 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Date: Wed, 15 Mar 89 11:06:53 EST
From: Guy Steele <gls@Think.COM>
To: masinter.pa@xerox.com
Cc: chapman%aitg.DEC@decwrl.dec.com, cl-cleanup@sail.stanford.edu
Subject: Cleanup Issue Status
> >+ FUNCTION-COMPOSITION
> >Synopsis: Add new functions
> >Version 5, 10-Feb-89
> >Status: Passed (as amended) Jan 89 X3J13
> I know this is picky, but I thought it was decided to fail this one
> completely and amend TEST-NOT-IF-NOT (I believe that was the related
> issue).
-- you may be right. I wish we had minutes. I guess I'll stick by my
summary unless I hear otherwise.
My notes show that the COMPLEMENT function was accepted and
all other parts of the proposal failed.
--Guy
My memory agrees with Guy's notes. We did spend several sessions on
this one and the waters got rather muddy at times.
∂15-Mar-89 0921 CL-Cleanup-mailer Re: Cleanup Issue Status
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89 09:21:37 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557486; Wed 15-Mar-89 12:18:32 EST
Date: Wed, 15 Mar 89 12:18 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Cleanup Issue Status
To: Dan L. Pierson <pierson@mist.encore.com>, Guy Steele <gls@Think.COM>,
masinter.pa@xerox.com, chapman%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8903151640.AA05621@mist.>
Message-ID: <19890315171827.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
My notes agree with Dan and Guy. It's complicated because the
COMPLEMENT portion of FUNCTION-COMPOSITION was moved into
TEST-NOT-IF-NOT by an amendment, which was where it was
actually passed. Back in FUNCTION-COMPOSITION, NEW-FUNCTIONS
was voted down unanimously and later COMPLEMENT-AND-CONSTANTLY
was voted down by something to something.
Date: Wed, 15 Mar 89 11:40:28 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Date: Wed, 15 Mar 89 11:06:53 EST
From: Guy Steele <gls@Think.COM>
> >+ FUNCTION-COMPOSITION
> >Synopsis: Add new functions
> >Version 5, 10-Feb-89
> >Status: Passed (as amended) Jan 89 X3J13
> I know this is picky, but I thought it was decided to fail this one
> completely and amend TEST-NOT-IF-NOT (I believe that was the related
> issue).
-- you may be right. I wish we had minutes. I guess I'll stick by my
summary unless I hear otherwise.
My notes show that the COMPLEMENT function was accepted and
all other parts of the proposal failed.
--Guy
My memory agrees with Guy's notes. We did spend several sessions on
this one and the waters got rather muddy at times.
∂15-Mar-89 0930 CL-Cleanup-mailer Issue: PRETTY-PRINT-INTERFACE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89 09:30:41 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557494; Wed 15-Mar-89 12:28:19 EST
Date: Wed, 15 Mar 89 12:28 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PRETTY-PRINT-INTERFACE (Version 1)
To: masinter.pa@Xerox.COM, Guy Steele <gls@Think.COM>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <890314-170500-2365@Xerox>
Message-ID: <19890315172817.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
If you're thinking about making a new version, I intend to comment on
this, but it's so huge that it's taking a long time. A very brief
summary of some of my likely comments is: I'm in favor of the general
idea of defining a standard pretty printer, but there are some problems
in the details of this proposal; part of this seems to resemble CLOS,
but is gratuitously(?) different; there doesn't seem to be any
concession to variable-width fonts, although I didn't find an explicit
statement of what units indentation and width are measured in; I wish to
God that Dick Waters hated FORMAT, because the grotesque FORMAT-based
syntax is going to make this a lot harder to pass.
∂15-Mar-89 0934 CL-Cleanup-mailer RE: Cleanup Issue Status
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89 09:33:57 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557496; Wed 15-Mar-89 12:30:17 EST
Date: Wed, 15 Mar 89 12:30 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: RE: Cleanup Issue Status
To: masinter.pa@Xerox.COM, chapman%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <890314-153644-2132@Xerox>
Message-ID: <19890315173018.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 14 Mar 89 15:35 PST
From: masinter.pa@Xerox.COM
> >+ DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
> >Version 3, 13-Jan-89
> >Status: passed, Jan 89 X3J13
> I believe this one was amended.
-- I have no amendments marked. Do you know what the amendment was?
> >+ PEEK-CHAR-READ-CHAR-ECHO
> >Version 3, 8-Oct-88, Released 8 Oct 88
> >Synopsis: PEEK-CHAR, READ-CHAR on streams made by MAKE-ECHO-STREAM
> >Status: Passed, Jan 89 X3J13
> I have this marked as amended.
-- I have no amendments made at the meeting. Do you?
My notes from January don't show any amendments to either of these.
∂15-Mar-89 0936 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from Aquinas.Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 09:36:35 PST
Received: from OCCAM.THINK.COM by Aquinas.Think.COM via INTERNET with SMTP id 124413; 15 Mar 89 12:34:29 EST
Date: Wed, 15 Mar 89 12:34 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
To: cl-cleanup@sail.stanford.edu
cc: X3J13@sail.stanford.edu
In-Reply-To: <890315-051405-3472@Xerox>
Message-ID: <19890315173420.1.BARMAR@OCCAM.THINK.COM>
Date: 15 Mar 89 05:13 PST
From: masinter.pa@xerox.com
Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE:CLARIFY):
Hooray! We finally got our collective acts together on this one!
barmar
∂15-Mar-89 0947 CL-Cleanup-mailer Issue: COPY-SYMBOL-PRINT-NAME
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89 09:47:16 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557507; Wed 15-Mar-89 12:44:21 EST
Date: Wed, 15 Mar 89 12:44 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COPY-SYMBOL-PRINT-NAME
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <8903151339.AA29246@decwrl.dec.com>
Message-ID: <19890315174412.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
I like COPY-SYMBOL-PRINT-NAME:EQUAL.
∂15-Mar-89 0959 CL-Cleanup-mailer Issue: TIME-ZONE-NON-INTEGER
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 09:59:06 PST
Received: from fafnir.think.com by Think.COM; Wed, 15 Mar 89 12:55:14 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 15 Mar 89 12:56:34 EST
Received: by verdi.think.com; Wed, 15 Mar 89 12:53:22 EST
Date: Wed, 15 Mar 89 12:53:22 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903151753.AA02688@verdi.think.com>
To: chapman%aitg.DEC@decwrl.dec.com, cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 14 Mar 89 16:55 EST <19890314215504.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: TIME-ZONE-NON-INTEGER
I strongly support TIME-ZONE-NON-INTEGER:ALLOW.
∂15-Mar-89 0948 X3J13-mailer Issue: GENSYM-NAME-STICKINESS (Version 1)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 09:48:17 PST
Received: from fafnir.think.com by Think.COM; Wed, 15 Mar 89 12:44:45 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 15 Mar 89 12:46:05 EST
Received: by verdi.think.com; Wed, 15 Mar 89 12:42:51 EST
Date: Wed, 15 Mar 89 12:42:51 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903151742.AA02653@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: masinter.pa@xerox.com's message of 14 Mar 89 14:56 PST <890314-145716-2049@Xerox>
Subject: Issue: GENSYM-NAME-STICKINESS (Version 1)
Does KMP intend that GENSYM not be sticky for an integer argument
as well? That is, there is no way to reset the counter?
--Guy
∂15-Mar-89 1045 CL-Cleanup-mailer Issue: GENSYM-NAME-STICKINESS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89 10:45:16 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557570; Wed 15-Mar-89 13:42:53 EST
Date: Wed, 15 Mar 89 13:42 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: GENSYM-NAME-STICKINESS (Version 1)
To: gls@Think.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8903151742.AA02653@verdi.think.com>
Message-ID: <890315134243.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
[X3J13 removed.]
Date: Wed, 15 Mar 89 12:42:51 EST
From: Guy Steele <gls@Think.COM>
Does KMP intend that GENSYM not be sticky for an integer argument
as well? That is, there is no way to reset the counter?
The great thing about the idea of a writeup is that it can stand alone,
regardless of what the author thinks. The writeup is not ambiguous --
it takes away the ability to reset the counter.
Happily, that means I can disagree with the writeup without disagreeing
with myself. It's obvious now that I think about it, that taking away
the ability to reset the counter makes it nearly useless to be able to
affect the counter, since you cannot simultaneously pass a name and a
counter (probably a mistake itself), and since you'd always get the
same number unless you did (GENSYM (INCF *MY-COUNTER*)) or some such.
I myself have never used the gensym-counter-resetting feature. I
have to say I don't think a lot of people use it either. The only use
I can really think of is for resetting a system so that you can get
the same set of GENSYM names again in a second run to a bunch of code.
If we were going to permit that, I would rather just document the
variable that holds the counter and not have it be done as a side-effect
of calling the function.
My basic feeling is that the "easy use" of GENSYM is best satisfied
if only a name is permissible, and use of any other kind argument is
starting to get into hair that it best done by people rolling their own
using MAKE-SYMBOL, FORMAT, and INCF.
My inclination at this point would be to document a variable:
*GENSYM-COUNTER*
which held the GENSYM counter, and to say that GENSYM could only take
a name argument (leaving other situations "undefined" so that
implementations could provide a graceful transition), and to say the
name argument is not sticky.
However, the only part of this I really care about is that the name
not be sticky. If you make any reasonable counterproposal that gives
me that one feature, odds are that I'll support it.
∂15-Mar-89 1057 CL-Cleanup-mailer Issue LOOP-AND-DISCREPANCY, version 1
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 10:56:37 PST
Received: from fafnir.think.com by Think.COM; Wed, 15 Mar 89 13:52:49 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 15 Mar 89 13:54:08 EST
Received: by verdi.think.com; Wed, 15 Mar 89 13:50:51 EST
Date: Wed, 15 Mar 89 13:50:51 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903151850.AA02865@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Cc: gls@Think.COM
Subject: Issue LOOP-AND-DISCREPANCY, version 1
Issue: LOOP-AND-DISCREPANCY
References: Loop Facility document X3J13/89-004
Related issues:
Category: CHANGE CLARIFICATION
Edit history: Version 1, 15-Mar-88 by Steele
Problem description:
The treatment of the AND conjunction in FOR/AS and WITH clauses is not
consistent. Examples of the use of WITH are also not consistent in this
respect.
Page 2-5 implies by example that when AND is used to join two
FOR/AS clauses, the word FOR or AS must occur after the word AND.
Page 2-31 has formal syntax specifying that when AND is used to join two
WITH clauses, the word WITH must *not* occur after the word AND. Examples
on that page are consistent with this specification.
Page 2-41 has an example in which WITH is repeated after AND.
Proposal (LOOP-AND-DISCREPANCY:NO-REITERATION):
Let stand the formal syntax for WITH.
Change the description of FOR/AS clauses to specify that when
two or more such clauses are joined with AND, clauses after the
first do not have FOR or AS before them.
The complete formal syntax for FOR/AS may be described as follows:
for-as ::= {FOR | AS} for-as-subclause {AND for-as-subclause}*
for-as-subclause ::= for-as-arithmetic | for-as-in-list
| for-as-on-list | for-as-equals-then
| for-as-across | for-as-hash | for-as-package
for-as-arithmetic ::= var [type-spec] ...
and so on.
Examples:
> (loop for x from 1 to 10 ;Corrected from X3J13/89-004, page 2-5
and y = nil then x
collect (list x y))
((1 NIL) (2 1) (3 2) (4 3) (5 4) (6 5) (7 6) (8 7) (9 8) (10 9))
> (loop with (a b) float = '(1.0 2.0) ;Corrected from X3J13/89-004, page 2-41
and (c d) integer = '(3 4)
and (e f)
return (list a b c d e f))
(1.0 2.0 3 4 nil nil)
Rationale:
The treatment of AND should be internally consistent. There is no reason
to repeat the FOR/AS keyword. Not repeating the keyword emphasizes that
the subclauses are functionally linked under the heading of WITH or FOR.
(Compare to the third use of AND in LOOP, to link clauses controlled
by WHEN/IF/UNLESS. One does not repeat the WHEN; rather, the clauses
grouped by AND are controlled by a single WHEN.)
Current practice:
Symbolics LOOP allows FOR to be included or omitted after AND,
with identical meanings. WITH may not be repeated after AND.
Cost to Implementors: Small?
Cost to Users: Possible incompatibility with existing implementors' extensions.
Cost of non-adoption: Utter confusion.
Performance impact: None.
Benefits: Consistent treatment of AND within LOOP.
Esthetics:
Absolutely none. We're talking about LOOP here.
Discussion:
Steele supports this proposal. It is a reversal of his previous
suggestion on the topic, thanks to feedback from Moon.
∂15-Mar-89 1111 CL-Cleanup-mailer Issue: COPY-SYMBOL-COPY-PLIST
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89 11:11:37 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557610; Wed 15-Mar-89 14:09:10 EST
Date: Wed, 15 Mar 89 14:09 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COPY-SYMBOL-COPY-PLIST
To: Masinter.pa@xerox.com
cc: Barry Margolin <barmar@Think.COM>, cl-cleanup@sail.stanford.edu
In-Reply-To: <19890110181742.7.BARMAR@OCCAM.THINK.COM>
Message-ID: <19890315190909.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
This one was marked with a * on your status report, but I don't
think it was ever brought up to the committee, and I don't think
it needs amendment. The discussion was just over whether
it's really a cleanup issue or an editorial issue. Let's just
vote on it as-is.
∂15-Mar-89 1127 CL-Cleanup-mailer Issue: REAL-NUMBER-TYPE (version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89 11:27:06 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557635; Wed 15-Mar-89 14:24:27 EST
Date: Wed, 15 Mar 89 14:24 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REAL-NUMBER-TYPE (version 3)
To: Masinter.pa@xerox.com
cc: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>, CL-Cleanup@Sail.Stanford.EDU,
DySak@STONY-BROOK.SCRC.Symbolics.COM, JGA@STONY-BROOK.SCRC.Symbolics.COM,
Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <19890113185020.8.CASSELS@GROUSE.SCRC.Symbolics.COM>
Message-ID: <19890315192425.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Your issue status for this one says
* REAL-NUMBER-TYPE
Synopsis: add REAL = (OR RATIONAL FLOAT) & range
Version 2, 08-Jan-89
Comment: lengthy dissent; discussion? coercion for comparitor?
Status: need new version
but I think this version is ready to vote up-or-down. Note that
there are two proposals; the REALP predicate function has been
separated out from the REAL data type.
Date: Fri, 13 Jan 89 13:50 EST
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Issue: REAL-NUMBER-TYPE
Forum: CLEANUP
References: Table 4-1.
Category: ADDITION
Edit history: 04-JAN-89, Version 1 by Bob Cassels, Don Sakahara, Kent Pitman,
and John Aspinall
08-JAN-89, Version 2 by Bob Cassels -- incorporate
Masinter's suggestion and make REAL a CLOS class
13-JAN-89, Version 3 by Cassels and Aspinall -- incorporate Marc LeBrun's
suggestions clarifying the relationship between CL
numeric type names and mathematical names
Status: For Internal Discussion
Problem Description:
There is no standard type specifier symbol for the CL type
'(OR RATIONAL FLOAT).
Proposal (REAL-NUMBER-TYPE:REAL):
Make REAL be a CL data type:
p.13 "Numbers"
Add: The NUMBER data type encompasses all of these kinds of
numbers. For convenience, there are names for some
subclasses of numbers. @i[Integers] and @i[ratios] are of
type RATIONAL. @i[Rational numbers] and @[floating-point
numbers] are of type REAL. @i[Real numbers] and @i[complex
numbers] are of type NUMBER.
Although the names of these types were chosen with the
terminology of mathematics in mind, the correspondences
are not always exact. Integers and ratios model the
corresponding mathematical concepts directly. Numbers
of the FLOAT type may be used to approximate real
numbers, both rational and irrational. The REAL type
includes all Common Lisp numbers which represent
mathematical real numbers, though there are
mathematical real numbers (irrational numbers)
which do not have an exact Common Lisp representation.
Only REAL numbers may be ordered using the <, >, <=,
and >= functions.
Compatibility note: The Fortran standard defines the term
"real datum" to mean "a processor approximation to the value
of a real number." In practice the Fortran "basic real" type
is the floating-point data type Common Lisp calls
SINGLE-FLOAT. The Fortran "double precision" type is
Common Lisp's DOUBLE-FLOAT. The Pascal "real" data type is
an "implementation-defined subset of the real numbers." In
practice this is usually a floating-point type, often what
Common Lisp calls DOUBLE-FLOAT.
A translation of an algorithm written in Fortran or Pascal
which uses "real" data usually will use some appropriate
precision of Common Lisp's FLOAT type. Some algorithms may
gain accuracy and/or flexibility by using Common Lisp's
RATIONAL or REAL types instead.
p.33 "Overlap, Inclusion, and Disjointness of Types":
Remove: The types RATIONAL, FLOAT, and COMPLEX are pairwise
disjoint subtypes of NUMBER.
Rationale: It might be thought that INTEGER and RATIO ...
Rationale: It might be thought that FIXNUM and BIGNUM ...
Add: The types RATIONAL and FLOAT are pairwise disjoint subtypes
of REAL.
The types REAL and COMPLEX are pairwise disjoint subtypes
of NUMBER.
Rationale: It might be thought that FIXNUM and BIGNUM should
form an exhaustive partition of the type INTEGER, that INTEGER
and RATIO should form an exhaustive partition of RATIONAL,
that RATIONAL and FLOAT should form an exhaustive partition of
REAL, and that REAL and COMPLEX should form an exhaustive
partition of NUMBER. These are all purposely avoided in order
to permit compatible experimentation with extensions to the
Common Lisp number system, such as the idea of adding explicit
representations of infinity or of positive and negative infinity.
p.43 Table 4-1 "Standard Type Specifier Symbols"
Add: REAL
p.49 "Type Specifiers that Abbreviate"
Add: (REAL low high)
Denotes the set of real numbers between low and high. ...
[As with RATIONAL and FLOAT.]
Make REAL a built-in CLOS class.
Proposal (REAL-NUMBER-TYPE:REALP):
Add a specific data type predicate REALP which tests for membership in
this type. [By analogy with NUMBERP.]
Test Case:
If a programmer wishes to test for "a number between 1 and 10", the
only current CL types would be '(or (rational 1 10) (float 1 10)) or
something like '(and numberp (not complexp) (satisfies range-1-10))
with (defun range-1-10 (real) (<= 1 real 10)). Both of these are
likely less efficient, and certainly less expressive than '(real 1 10).
Rationale:
Mathematics has a name for (OR RATIONAL FLOAT) -- it is "real".
This class is important because it is all the numbers which can be
ordered.
Throughout the "Numbers" chapter, the phrase "non-complex number" is
used.
MAX, MIN, p. 198 "The arguments may be any non-complex numbers."
CIS p. 207 "The argument ... may be any non-complex number."
Current Practice:
Probably nobody does this.
Cost to Implementors:
Some work is necessary to add this name. But since the underlying
type already exists the amount of work should be minimal.
Cost to Users:
Since this is an upward-compatible extension, it may be ignored by
users.
Cost of Non-Adoption:
Occasional inconvenience and/or inefficiency.
Benefits:
Mathematical clarity.
Ability to do CLOS method dispatch on the type.
Aesthetics:
As mentioned under "rationale," this would be a more concise way to
express a common programming idiom.
Discussion:
The name "non-complex number" is incorrect because future
implementations may wish to include numerical types which are neither
complex nor real. [e.g. pure imaginary numbers or quaternions]
The name "scalar" is incorrect because the mathematical concept of
scalar may indeed include complex numbers.
Fortran and Pascal use the name "real" to mean what CL calls
SINGLE-FLOAT. That should cause no significant problem, since a Lisp
program written using the type REAL will do mathematically what the
equivalent Fortran program would do. This is because Fortran's "real"
data-type is a subtype of the CL REAL type. The only differences
might be that the Lisp program could be less efficient and/or more
accurate.
A survey of several Fortran and Pascal books shows that the distinction
between INTEGER and REAL is that REAL numbers may have fractional
parts, while INTEGERs do not. Later discussions explain that REALs
cover a greater range. Much later discussions cover precision
considerations, over/underflow, etc. So the average Fortran or Pascal
programmer should be completely comfortable with the proposed Lisp
concept of REAL.
∂15-Mar-89 1138 CL-Cleanup-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
Received: from Aquinas.Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 11:34:16 PST
Received: from OCCAM.THINK.COM by Aquinas.Think.COM via CHAOS with CHAOS-MAIL id 124421; Wed 15-Mar-89 13:58:59 EST
Date: Wed, 15 Mar 89 13:58 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
To: masinter.pa@xerox.com
cc: kmp@symbolics.com, cl-cleanup@sail.stanford.edu
In-Reply-To: <890314-144336-2004@Xerox>
Message-ID: <19890315185842.5.BARMAR@OCCAM.THINK.COM>
Sorry for the delay. Here's a version with my amendments merged in.
Actually, it looks like it might read better if all the NCONC stuff were
pulled out of this proposal and made a separate issue; right now, most
of the sections say general things and then have a paragraph that begins
with "In the NCONC case...". In that case, I suggest that the text
Amemdment I from my 14 February mail be used verbatim as the proposal.
barmar
Issue: REMF-DESTRUCTION-UNSPECIFIED
References: (SETF (GET ...) ...), REMPROP, (SETF (GETF ...) ...),
REMF (pp165-167); NREVERSE (p248); DELETE, DELETE-IF,
DELETE-DUPLICATES, NSUBSTITUTE, NSUBSTITUTE-IF (pp254-256);
NCONC, NRECONC (p269); NUNION, NINTERSECTION,
NSET-EXCLUSIVE-OR (pp276-279).
Category: CLARIFICATION/CHANGE
Edit history: 11-Feb-87, Version 1 by Dave Andre (DLA@Symbolics.COM)
29-Oct-87, Version 2 by Pitman (flesh out proposals)
28-Nov-88, Version 3 by Pitman (revised presentation)
29-Nov-88, Version 4 by Pitman (slight editing per DLA)
15-Mar-89, Version 5 by Margolin (amendments discussed in
Hawaii, removed -NOT functions)
Status: For Internal Discussion
Problem Description:
Currently, the exact nature of the side-effect performed by list
modification routines is not specified.
Either the specific modifications allowed should be specified so that
programmers can rely on them and implementors can avoid accidentally
causing problems by introducing well-meaning optimizations, or else
the documentation should explicitly state that the effects are
unspecified so that programmers will not depend on them and
implementors will feel comfortable about doing interesting optimizations.
Proposal (REMF-DESTRUCTION-UNSPECIFIED:EXPLICITLY-VAGUE-EXCEPT-NCONC):
Clarify that the way in which the destructive behavior of the
operators below is achieved is explicitly vague in a number of ways,
in order to provide individual implementations the necessary
flexibility to do useful optimizations.
(SETF (GETF place indicator) value)
is permitted to either SETF place or to SETF any part, CAR or
CDR, of the top-level list structure held by that place.
(REMF place indicator)
is permitted to either SETF place or to SETF any part, CAR or
CDR, of the top-level list structure held by that place.
(SETF (GET symbol indicator) value)
is constrained to behave exactly the same as
(SETF (GETF (SYMBOL-PLIST symbol) indicator) value).
(REMPROP symbol indicator)
is constrained to behave exactly the same as
(REMF (SYMBOL-PLIST symbol) indicator).
(NREVERSE sequence)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure in that sequence.
when sequence is an array is permitted to re-order the elements
of the given sequence in order to produce the resulting array.
(DELETE object sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure held in that sequence.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(DELETE-IF test sequence ...)
is constrained to behave exactly like
(DELETE NIL sequence
:TEST #'(LAMBDA (IGNORE ITEM) (FUNCALL test ITEM))
...).
(DELETE-DUPLICATES sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure held in that sequence.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(NSUBSTITUTE new-object old-object sequence ...)
(NSUBSTITUTE-IF new-object test sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure in that sequence.
when sequence is an array is permitted to SETF the contents of
any cell in that array which must be replaced by NEW-OBJECT.
Note, however, that since this side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
(NRECONC list tail)
is constrained to have side-effect behavior equivalent to:
(NCONC (NREVERSE list) tail).
(NUNION list1 list2 ...)
(NINTERSECTION list1 list2 ...)
(NSET-EXCLUSIVE-OR list1 list2 ...)
is permitted to SETF any part, CAR or CDR, of the top-level of
any of the given lists.
Note, however, that since this side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
(NCONC . lists)
is defined using the following recursive relationship:
(NCONC) => NIL
(NCONC NIL . args) == (NCONC . args)
(NCONC arg) => arg
(NCONC arg1 arg2) has the side effect of (RPLACD (LAST arg1) arg2),
and returns arg1
(NCONC arg1 arg2 . args) == (NCONC (NCONC arg1 arg2) . args)
[If a previous cleanup issue prohibited NIL as a non-last argument
then ignore the (NCONC NIL . args) case.]
Note: The above clarifications are not intended as complete functional
descriptions. They are intended to augment (rather than to replace)
other descriptions already in effect.
Test Cases:
For GETF...
(SETQ FOO (LIST 'A 'B 'C 'D 'E 'F)) ==> (A B C D E F)
(SETQ BAR (CDDR FOO)) ==> (C D E F)
(REMF FOO 'C)
BAR ==> ??
In Symbolics Common Lisp, BAR holds (C D E F).
CLtL allows other interpretations. eg, BAR might hold
(C), (NIL), (C NIL) or (C D).
Under this proposal, any of these interpretations (and others as well)
would still be valid
For DELETE...
(SETQ FOO (LIST 'A 'B 'C)) ==> (A B C)
(SETQ BAR (CDR FOO)) ==> (B C)
(SETQ FOO (DELETE 'B FOO)) ==> (A C)
BAR ==> ??
(EQ (CDR FOO) (CAR BAR)) ==> ??
In Symbolics Common Lisp, these last two expressions return ((C)) and T.
Under this proposal, either of these interpretations (and others
as well) would be valid.
For NCONC...
(SETQ FOO (LIST 'A 'B 'C 'D 'E)
BAR (LIST 'F 'G 'H 'I 'J)
BAZ (LIST 'K 'L 'M)) => (K L M)
(SETQ FOO (NCONC FOO BAR BAZ)) => (A B C D E F G H I J K L M)
FOO => (A B C D E F G H I J K L M)
BAR => (F G H I J K L M)
BAZ => (K L M)
(SETQ FOO (LIST 'A 'B 'C 'D 'E)
BAR (LIST 'F 'G 'H 'I 'J)
BAZ (LIST 'K 'L 'M)) => (K L M)
(SETQ FOO (NCONC NIL FOO BAR NIL BAZ)) => (A B C D E F G H I J K L M)
FOO => (A B C D E F G H I J K L M)
BAR => (F G H I J K L M)
BAZ => (K L M)
Rationale:
Implementations already vary widely on their implementation techniques
for these functions. This effectively clarifies the status quo, making
it more clear to programmers what they may rely upon in portable code.
In the case of NCONC, however, the precise definition is useful because
it is what users expect, it is how NCONC has been defined for many
years, and it is how current implementations generally work. It may
not always be the most efficient way (e.g. it may result in invisible
pointers in CDR-coded implementations), but callers of NCONC probably
use it specifically for its precise side effects.
Current Practice:
All valid implementations are believed to comply with the vague
definitions. Symbolics Genera 7.2 and Sun Common Lisp 2.1.3 appear to
conform to the NCONC spec.
Cost to Implementors:
None. This is probably the status quo for most implementors. If there
are any implementations that don't implement NCONC as above (which I
doubt) they will have to be changed.
Cost to Users:
This change would not affect programs coded with "good programming
practice". That is, only programs which rely on currently undocumented
features would be in any danger of breaking. In fact, those programs
are already in such danger, and this change to the documentation would
just publicize it. The clarification would -encourage- good programming
practice by warning people to only obey the published contract of the
above-mentioned functions.
There is, however, no automatic technique for making this check for
programs already in error. Bugs due to unexpected side-effects are in
general among the hardest to reckon with.
Cost of Non-Adoption:
Programmers may naively believe there is only one possible or reasonable
implementation of these functions. Some implementors may shy away from
reasonable optimizations out of a paranoid belief that deviating from
some vague, unspoken rules will lead to programmer unrest. Making these
things explicitly vague clarifies the implementor's rights in a way that
permits numerous useful optimizations.
Benefits:
Users would be discouraged from taking advantage of subtle details
of these destructive operations because such details would be explicitly
not guaranteed to be portable.
Implementations can improve performance of many of the above-mentioned
functions when they are not under the constraint to implement them
in a highly constrained fashion. For example, in Symbolics systems,
DELETE of a cdr-coded list could use the implementation primitive
%CHANGE-LIST-TO-CONS rather than RPLACD to avoid creating forwarding
pointers.
Garbage collection effectiveness can also be improved. For example,
all of the destructive operations which remove objects (eg, REMF)
could remove CAR pointers to removed objects which are more volatile
than the list itself, assisting the garbage collector and thereby
improving memory usage and paging performance.
Tightening the definition of NCONC permits users to predict their
programs' behavior more precisely.
Non-Benefits:
Users who inadvertently depend on side-effect behavior may be rudely
surprised when moving between implementations.
Compatibility with older Lisp dialects is diminished.
Implementors have less flexibility in implementing NCONC efficiently.
Performance Impact:
Metering in Symbolics test systems have shown that there are substantial
performance gains to be had by allowing implementations flexibility in
these areas.
In the case of NCONC, this implementation flexibility, and hence
potential performance improvements, is sacrificed.
Aesthetics:
Most of these functions implement abstract operations. For example,
REMPROP implements an abstract operation on a "property list".
Proper language design should not encourage people to delve below the
level of abstraction into the nitty gritty.
NCONC is a "less abstract" function than the rest of the functions
described above. It is usually used precisely because of the way it
interacts with list implementation.
Discussion:
Andre's original version of this proposal pushed for explicitly vague
descriptions of these functions' side-effect behavior. He believes
that if users want more predictability from these functions, they
should write private variants that implement whatever predictability
they require.
Pitman originally opposed this position because he weighed portability
a higher concern. Since the original discussion, however, his views on
how to resolve this priority have been refined, and he now believes
that leaving things vague is appropriate. As such, he now supports what
is effectively Andre's original proposal.
Pitman and Andre supported version 4. [I don't know how they feel
about v5 -- Barmar].
∂15-Mar-89 1145 CL-Cleanup-mailer Issue: REAL-NUMBER-TYPE (version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89 11:44:52 PST
Received: from GROUSE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557688; Wed 15-Mar-89 14:42:23 EST
Date: Wed, 15 Mar 89 14:42 EST
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REAL-NUMBER-TYPE (version 3)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, Masinter.pa@xerox.com
cc: Cassels@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@Sail.Stanford.EDU,
DySak@STONY-BROOK.SCRC.Symbolics.COM, JGA@STONY-BROOK.SCRC.Symbolics.COM,
Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <19890315192425.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890315194221.4.CASSELS@GROUSE.SCRC.Symbolics.COM>
Date: Wed, 15 Mar 89 14:24 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Your issue status for this one says
* REAL-NUMBER-TYPE
Synopsis: add REAL = (OR RATIONAL FLOAT) & range
Version 2, 08-Jan-89
Comment: lengthy dissent; discussion? coercion for comparitor?
Status: need new version
but I think this version is ready to vote up-or-down. Note that
there are two proposals; the REALP predicate function has been
separated out from the REAL data type.
Date: Fri, 13 Jan 89 13:50 EST
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Issue: REAL-NUMBER-TYPE
Forum: CLEANUP
References: Table 4-1.
Category: ADDITION
Edit history: 04-JAN-89, Version 1 by Bob Cassels, Don Sakahara, Kent Pitman,
and John Aspinall
08-JAN-89, Version 2 by Bob Cassels -- incorporate
Masinter's suggestion and make REAL a CLOS class
13-JAN-89, Version 3 by Cassels and Aspinall -- incorporate Marc LeBrun's
suggestions clarifying the relationship between CL
numeric type names and mathematical names
Status: For Internal Discussion
We should change "current practice" to note that TI Lisp includes both
the REAL type and REALP predicate.
∂15-Mar-89 1147 CL-Cleanup-mailer Issue: MAKE-STRING-FILL-POINTER (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89 11:47:34 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557698; Wed 15-Mar-89 14:45:08 EST
Date: Wed, 15 Mar 89 14:45 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: MAKE-STRING-FILL-POINTER (Version 1)
To: Masinter.pa@xerox.com
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <19881021012549.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Message-ID: <19890315194500.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Your status file says:
* MAKE-STRING-FILL-POINTER
Synopsis: extend MAKE-STRING to take a fill-pointer?
Version 1, 20-Oct-88
Comments: extend to take other keywords? MAKE-STRING should return
simple string always? Interaction with character proposal
Status: awaiting new version
But I don't have any record of any discussion that would warrant
a new version. Also I don't believe the comments quoted above
are relevant to this issue. If you have any discussion I should
see, and suggestions for a new version, could you forward them to
me? If you send me that I'll make a new version. Otherwise I
think the old version is ready to vote on, up-or-down.
Date: Thu, 20 Oct 88 21:25 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Issue: MAKE-STRING-FILL-POINTER
References: CLtL p.302
Related issues: none that I know of
Category: ADDITION
Edit history: Version 1, 20-Oct-88, by Moon, for discussion
Problem description:
Once again I lost because I expected to be able to use MAKE-STRING
to create a string with a fill-pointer, and I couldn't. I had to use
a more long-winded MAKE-ARRAY call instead.
Proposal (MAKE-STRING-FILL-POINTER:ALLOW):
Give MAKE-STRING a :FILL-POINTER argument, with the same syntax and
semantics as the :FILL-POINTER argument to MAKE-ARRAY.
Examples:
(make-string 80 :fill-pointer 0)
Test Cases:
See examples.
Rationale:
I frequently expect it to be allowed and am surprised when it's not.
Current practice:
I know of no implementations that support this.
Cost to Implementors:
5 cents.
Cost to Users:
none
Cost of non-adoption:
none
Performance impact:
none
Benefits:
Increased language consistency.
Esthetics:
Increased language consistency.
Discussion:
Other MAKE-ARRAY options that one might want to allow, but are
not already allowed or proposed, are :INITIAL-CONTENTS, :ADJUSTABLE,
:DISPLACED-TO, and :DISPLACED-INDEX-OFFSET. A strong case could be
made for :ADJUSTABLE (I use an implementation where it doesn't matter,
so I don't care about that), I don't think anyone would care about the
other three.
∂15-Mar-89 1208 CL-Cleanup-mailer Issue status
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 15 Mar 89 12:07:44 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA29800; Wed, 15 Mar 89 12:05:27 PST
Message-Id: <8903152005.AA29800@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for cl-cleanup@sail.stanford.edu; id AA29800; Wed, 15 Mar 89 12:05:27 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 15 Mar 89 14:29
To: cl-cleanup@sail.stanford.edu
Subject: Issue status
> > >+ FUNCTION-COMPOSITION
> > >Synopsis: Add new functions
> > >Version 5, 10-Feb-89
> > >Status: Passed (as amended) Jan 89 X3J13
> > I know this is picky, but I thought it was decided to fail this one
> > completely and amend TEST-NOT-IF-NOT (I believe that was the related
> > issue).
>
> -- you may be right. I wish we had minutes. I guess I'll stick by my
> summary unless I hear otherwise.
>
>My notes show that the COMPLEMENT function was accepted and
>all other parts of the proposal failed.
Yes but COMPLEMENT was an amendment to TEST-NOT-IF-NOT. This was how Walter
and I both recorded it. Anyway, it seems to be clear what happened even
if the status of the issues isn't.
∂15-Mar-89 1227 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL (Version 9)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 15 Mar 89 12:26:28 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa11885; 15 Mar 89 20:13 GMT
Date: Wed, 15 Mar 89 20:10:25 GMT
Message-Id: <2348.8903152010@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: issue PROCLAIM-LEXICAL (Version 9)
To: masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@com.xerox's message of 13 Mar 89 17:14 PST
> The last version of PROCLAIM-LEXICAL I have is Version 9, which was
> distributed before the Hawaii meeting. There were the various comments on
> Version 9, amendments proposed but not passed, and, more recently, mail
> from Sandra Loosemore, Jeff Dalton, JonL White, Gail Zacharias and David
> Moon.
>
> However, there's no new version.
Last I knew, JonL had said there were "conceptual" problems. I said
that, if there were, I didn't understand what they were. And that was
the last I saw on this topic. Maybe I'd managed to convince JonL?
In Hawaii, some people objected on grounds of efficiency or because
they didn't have a spare bit (see the Rees suggestion in the
proposal).
I think the ammendments proposed in Hawaii might have answered both
kinds of objection, but I remember thinking that some of the
ammendments were unnecessary or wrong.
Perhaps those who still have objections can say what they would like
to change and why.
∂15-Mar-89 1229 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 15 Mar 89 12:27:33 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa09545; 15 Mar 89 15:59 GMT
Date: Wed, 15 Mar 89 15:57:02 GMT
Message-Id: <1423.8903151557@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 1)
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, Masinter.PA@xerox.com
In-Reply-To: Kent M Pitman's message of Tue, 14 Mar 89 20:43 EST
Cc: CL-Cleanup@sail.stanford.edu
> All in all, though, I like somebody's (Gray's?) suggestion of a
> function rather than a table. The default being #'CHAR-UPCASE, and
> #'IDENTITY being another obvious choice.
It was indeed Gray's suggestion.
I also prefer the function to the keyword. However, can we allow
arbitrary functions or would that cause problems for the printer?
> The reason I like the function rather than the keyword is that you
> don't have to initially provide the alternate functionality -- user's
> can add it.
Can they or do the functions have to be from a set known to the
printer?
> In the case of the keyword, it has to be given by the system so you're
> at the mercy of the implementors as to which options you get. I think
> this feature is worth the added complexity.
I am somewhat uneasy about allowing arbitrary translations rather
than just having a case switch. I would rather have the general
mechanism but not if it would cause prople to oppose an issue they
would otherwise support.
-- Jeff
∂15-Mar-89 1256 CL-Cleanup-mailer PRETTY-PRINT-INTERFACE, version 3 (supersedes 2 sent an hour ago!)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 12:54:51 PST
Received: from fafnir.think.com by Think.COM; Wed, 15 Mar 89 15:50:57 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 15 Mar 89 15:52:16 EST
Received: by verdi.think.com; Wed, 15 Mar 89 15:49:04 EST
Date: Wed, 15 Mar 89 15:49:04 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903152049.AA03416@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Subject: PRETTY-PRINT-INTERFACE, version 3 (supersedes 2 sent an hour ago!)
Version 3 is changed from version 1 as follows:
adds a functional interface to supplement the interface through FORMAT,
and reflects comments by Barrett and Pierson.
The document attached to version 1 has been omitted here, as the
mailer choked on it. It should logically be inserted before the
functional interface attached here.
--Guy
Issue: PRETTY-PRINT-INTERFACE
References: Description of XP by Dick Waters (attached)
*PRINT-PRETTY* (CLtL p. 371)
WRITE (CLtL p. 382)
PPRINT (CLtL p. 383)
FORMAT (CLtL pp. 385-407)
FORMAT ~T directive (CLtL pp. 398-399)
FORMAT ~< directive (CLtL pp. 404-406)
Related issues:
Category: CLARIFICATION CHANGE ADDITION
Edit history: Version 1, 24-Feb-89 by Steele
Version 2, 15-Mar-89 by Steele and Waters
Version 3, 15-Mar-89 by Steele
Problem description:
At present Common Lisp provides no specification whatsoever of how
pretty-printing is to be accomplished, and no way for the user to control
it. In particular, there is no protocol by which a user can write a
print-function for a structure, or a method for PRINT-OBJECT, that will
interact smoothly with the built-in pretty-printer in a portable manner.
Proposal (PRETTY-PRINT-INTERFACE:XP):
Adopt the interfaces and protocols of the XP pretty-printer by Dick Waters,
described in full in the attached 12-page document. Here is a very brief
summary of the proposal.
New variables: *PRINT-DISPATCH*
*PRINT-RIGHT-MARGIN*
*DEFAULT-RIGHT-MARGIN*
*PRINT-MISER-WIDTH*
*PRINT-LINES*
*LAST-ABBREVIATED-PRINTING*
New function: COPY-PRINT-DISPATCH
New macro: DEFINE-PRINT-DISPATCH
New FORMAT directives: ~W ~_ ~I ~:T ~/name/ ~<...~:>
New # reader macro: #"..."
The function WRITE is extended to accept additional keyword arguments
:DISPATCH, :RIGHT-MARGIN, :LINES, and :MISER-WIDTH corresponding to the
first four of the new variables.
Finally, wherever in the attached document it says that certain constructs
support depth abbreviation and circularity detection, it should be noted
that this is so a fortiori, because *all* printing operations support them
properly. Therefore, while the statements are correct, the possibly
misleading implication that they are the only way to achieve such
detection should be rectified if the text is taken over into the standard.
Examples: See attached document.
Rationale:
There ought to be a good user interface to the pretty printer.
This is the only proposal for which there is a portable implementation
that has seen extensive use and is being made freely available.
Current practice:
XP son of PP son of GPRINT son of PRINT* is the latest in a line of pretty
printers that goes back 13 years. All of these printers use essentially
the same basic algorithm and conceptual interface. Further, except for
PRINT*, which was implemented solely to satisfy the author's personal
needs, each of these printers has had extensive use. XP has been in
experimental use as the pretty printer in CMU Common Lisp for 6 months. PP
has been the pretty printer in DEC Common Lisp for the past 3 years. Prior
to three years ago, GPRINT was used for 2 years as the pretty printer in
DEC Common Lisp. In addition, GPRINT has been the pretty printer in
various generations of Symbolics Lisp for upwards of 5 years.
(See Waters R.C., "User Format Control in a Lisp Prettyprinter", ACM TOPLAS,
5(4):513--531, October 1983.)
Cost to Implementors:
A fair amount of effort (perhaps a few man-weeks at most).
Source code for XP is available to all comers from Dick Waters, and
the system is documented in great detail:
Waters, Richard C., "XP: A Common Lisp Pretty Printing System",
Artificial Intelligence Laboratory Technical Memo 1102,
Massachusetts Institute of Technology, Cambridge MA, March 1989.
Cost to Users: None (I think). This is an upward-compatible extension.
Cost of non-adoption: Continued inability for user print-functions
to interact with the pretty-printer in a useful and portable manner.
Performance impact: XP is claimed to be quite fast.
Benefits: User control of pretty-printing in a portable manner.
Esthetics:
Using ~<...~:> may strike some as uncomfortably close in the syntactic
space of FORMAT directives to the existing ~<...~>. However, it is very
unlikely that both of these directives (pretty-print logical block and
columnar justification, respectively) will be used in the same call to
FORMAT. Previous versions of XP used ~!...~. instead of ~<...~:> but this
made FORMAT strings very difficult to read; it is preferable to have
a directive that looks like matching brackets of some sort.
Dan Pierson comments: You might mention that some people will undoubtedly
find piling more hair on FORMAT ugly (of course these same people may
well find FORMAT in general ugly :-)).
Discussion:
Zetalisp used ~:T to mean pixelwise tabulation, so the use of ~:T
suggested here may be a problem. If so, another suggestion for naming
this directive would be appropriate.
The ~/.../ directive is already in Zetalisp, and is not an idea new
to this proposal.
Guy Steele and Dick Waters strongly support this proposal. (As an example,
Guy Steele has a portable simulator for Connection Machine Lisp, and would
like very much to have xappings and xectors pretty-print properly.)
Dan Pierson comments: You can add me to the list of strong supporters of
this proposal. While the proposal is long and complex, it is supported by
a long history of usage in several different Lisp environments. Unlike
some earlier members of this family, this version fits cleanly enough into
the rest of Common Lisp to warrant standardization.
The utility of *PRINT-LINES* becomes more obvious if it is pointed out
that Dick's pretty printers are implemented to print each line as it
is computed. This means that a small value for *PRINT-LINES* saves
significant time as well as output medium space. In fact, many people
find that a very pleasant REP loop is created by setting *PRINT-LINES*
to a value from 1-4, *PRINT-PRETTY* to T, and defining a short-name
function (say (PP*)) that funcalls *LAST-ABBREVIATED-PRINTING* with
abbreviation bound off. This is almost as fast and compact as, and
MUCH more readable than, a non-pretty-printing REP loop.
The advantages of compiled format strings (format functions) should be
brought out as benefits in their own right. The current proposal just
mentions them as a minor feature of XP.
At first this struck me a very cute end run around the failure of
STREAM-INFO, then I realized that one of the problems with STREAM-INFO
may have been that it was a standard at the wrong level. STREAM-INFO
permitted people to use XP, but not to count on it. This proposal
makes it possible to write portable code whose new data structures and
language elements print correctly in whatever Common Lisp environment
they're run in. [End of comments by Pierson]
!
Functional Interface
The primary interface to operations for dynamically determining the
arrangement of output is provided through FORMAT. This is done,
because FORMAT strings are typically the most convenient way of
interacting with pretty printing. However, these operations have
nothing inherently to do with FORMAT per se. In particular, they can
also be accessed via the six functions and macros below.
WITHIN-LOGICAL-BLOCK (&KEY :STREAM :VAR :ARG [Macro]
:PREFIX :PER-LINE-PREFIX :SUFFIX)
&BODY BODY
In the manner of ~<...~:>, this macro causes printing to be
grouped into a logical block. The value NIL is always returned.
:STREAM specifies the stream the logical block is to be printed on.
:STREAM defaults to *STANDARD-OUTPUT* and follows the standard
conventions for stream arguments to output functions---NIL stands for
*STANDARD-OUTPUT* and T stands for *TERMINAL-IO*.
:VAR (which defaults to *STANDARD-OUTPUT*) must be a symbol other than
T or NIL. :VAR is bound to a special kind of stream that supports
dynamic decisions about the arrangement of output.
The BODY can contain any arbitrary Lisp forms. All the standard
printing functions (e.g., WRITE, PRINC, TERPRI) can be used to print
output into :VAR. All and only the output sent to :VAR is treated as
being in the logical block. It is an error for the BODY to send any
output directly to :STREAM.
:SUFFIX (which defaults to the null string) specifies a suffix that is
printed just after the logical block. :PREFIX specifies a prefix to be
printed before the beginning of the logical block. :PER-LINE-PREFIX
specifies a prefix that is printed before the block and at the
beginning of each new line in the block. It is an error for :PREFIX
and :PRE-LINE-PREFIX to both be used. If neither is used, a :PREFIX of
the null string is assumed.
:ARG (which defaults to NIL) is interpreted as being a list that BODY
is responsible for printing. If :ARG is not a list, it is printed
using WRITE. If *PRINT-CIRCLE* is not NIL and :ARG is a circular
reference to a cons, then an appropriate #n# marker is printed. If
*PRINT-LEVEL* is not NIL and the logical block is at a dynamic nesting
depth of greater than *PRINT-LEVEL* in logical blocks, # is printed.
If either of the three conditions above occures, the special output is
printed on :STREAM and the BODY is skipped along with the printing of
the prefix and suffix.
CONDITIONAL-NEWLINE KIND &OPTIONAL (STREAM *STANDARD-OUTPUT*) [Function]
CONDITIONAL-NEWLINE is the functional equivalent of ~_. STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions. The KIND argument specifies
the style of conditional newline. It must be one of :LINEAR, :FILL,
:MISER, or :MANDATORY. If STREAM is a special stream bound by
WITHIN-LOGICAL-BLOCK, a conditional newline is sent to it. Otherwise,
CONDITIONAL-NEWLINE has no effect. The value NIL is always returned.
LOGICAL-BLOCK-INDENT KIND N &OPTIONAL (STREAM *STANDARD-OUTPUT*) [Function]
LOGICAL-BLOCK-INDENT is the functional equivalent of ~I, STREAM
argument (which defaults to *STANDARD-OUTPUT*) follows the standard
conventions for stream arguments to printing functions. N specifies
the amount of indentation. If KIND is :FROM-START, this indentation is
relative to the start of the enclosing block (as for ~I). If KIND is
:FROM-POSITION, the indentation is relative to the current output
position (as for ~:I). It is an error for KIND to take on any other
value. If STREAM is a special stream bound by WITHIN-LOGICAL-BLOCK,
LOGICAL-BLOCK-INDENT sets the indentation in the innermost enclosing
logical block. Otherwise, LOGICAL-BLOCK-INDENT has no effect. The
value NIL is always returned.
LOGICAL-BLOCK-TAB KIND COLNUM COLINC &OPTIONAL (STREAM *STANDARD-OUTPUT*)
LOGICAL-BLOCK-TAB is the functional equivalent of ~T. STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions. The arguments COLNUM and
COLINC correspond to the two numeric parameters to ~T. The KIND
argument specifies the style of tabbing. It must be one of :LINE (tab
using ~T), :BLOCK (tab using ~:T), :LINE-RELATIVE (tab using ~@T), or
:BLOCK-RELATIVE (tab using ~:@T). If STREAM is a special stream bound
by WITHIN-LOGICAL-BLOCK, tabbing is performed. Otherwise,
LOGICAL-BLOCK-TAB has no effect. The value NIL is always returned.
LOGICAL-BLOCK-POP ARGS &OPTIONAL (STREAM *STANDARD-OUTPUT*) [Macro]
LOGICAL-BLOCK-COUNT &OPTIONAL (STREAM *STANDARD-OUTPUT*) [Macro]
LOGICAL-BLOCK-POP is identical to POP except that it supports
*PRINT-LENGTH* and *PRINT-CIRCLE*. It is an error to use
LOGICAL-BLOCK-POP anywhere other than syntactically nested within a
call on WITHIN-LOGICAL-BLOCK.
ARGS must be a symbol or expression acceptable to POP. STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions. If STREAM is a special stream
bound by WITHIN-LOGICAL-BLOCK, then LOGICAL-BLOCK-POP performs the
special operations described below. Otherwise, LOGICAL-BLOCK-POP is
identical to POP.
Each time LOGICAL-BLOCK-POP is called, it performs three tests. if
ARGS is not a cons, ". " is printed followed by ARGS. If
*PRINT-LENGTH* is NIL and LOGICAL-BLOCK-POP has already been called
*PRINT-LENGTH* times within the immediately containing logical block,
"..." is printed. If *PRINT-CIRCLE* is not NIL, and ARGS is a circular
reference, then ". " is printed followed by an appropriate #n# marker.
If either of the three conditions above occurs, the special output is
printed on :STREAM and the execution of the immediately containing
WITHIN-LOGICAL-BLOCK is terminated except for the printing of the
suffix. Otherwise, LOGICAL-BLOCK-POP pops the top value off of ARGS
and returns this value.
LOGICAL-BLOCK-COUNT is identical to LOGICAL-BLOCK-POP except that it
does not take an ARGS argument, always returns NIL, and only performs
the second test discussed above. It is useful when the components of a
non-list are being printed.
Using the functions above, TABULAR-STYLE could be defined as follows.
(defun tabular-style (stream list &optional (colon? T) atsign?
(tabsize nil))
(declare (ignore atsign?))
(if (null tabsize) (setq tabsize 16))
(within-logical-block (:var s :stream stream :arg list
:prefix (if colon? "(" "")
:suffix (if colon? ")" ""))
(when list
(loop (write (logical-block-pop list s) :stream s)
(if (null list) (return nil))
(write-char #\space s)
(logical-block-tab :block-relative 0 tabsize s)
(conditional-newline :fill s)))))
The function below prints a vector using #(...) notation.
(defun print-vector (v *standard-output*)
(within-logical-block (:prefix "#(" :suffix ")")
(let ((end (length v)) (i 0))
(when (plusp end)
(loop (logical-block-count)
(write (aref v i))
(if (= (incf i) end) (return nil))
(write-char #\space)
(conditional-newline :fill))))))
[End of attached document]
∂15-Mar-89 1306 CL-Cleanup-mailer Issue: GENSYM-NAME-STICKINESS, version 2
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 13:05:38 PST
Received: from fafnir.think.com by Think.COM; Wed, 15 Mar 89 16:01:40 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 15 Mar 89 16:02:59 EST
Received: by verdi.think.com; Wed, 15 Mar 89 15:59:47 EST
Date: Wed, 15 Mar 89 15:59:47 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903152059.AA03501@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: GENSYM-NAME-STICKINESS, version 2
Cc: gls@Think.COM
Version 2 proposes to provide access to the counter state.
Additional Comments include:
"... it's ... late to consider things like this ..."
"YAY!!! This is what "cleanup" is for. Go For It! "
"Sounds like a good idea to me."
!
Issue: GENSYM-NAME-STICKINESS
Forum: Cleanup
References: GENSYM (p169)
Category: CHANGE
Edit history: 14-Feb-89, Version 1 by Pitman
15-Mar-89, Version 2 by Steele
Problem Description:
Many people avoid use of the argument to GENSYM because the argument
is `sticky' and such stickiness can lead to confusion. The problem is
that if any application (usually a macro) uses the gensym argument at
all, then all applications are forced to. If they do not, they risk
finding that the `helpful' argument supplied in some previous call will
be harmful to them.
Proposal (GENSYM-NAME-STICKINESS:WASH-HANDS):
Define that if an optional argument is given to GENSYM, it does NOT
have a side-effect on GENSYM's internal state.
Define that the function GENSYM-COUNTER takes a non-negative integer n
and modifies the internal state of GENSYM so that the next symbol
generated will be number n. GENSYM-COUNTER returns the old value
of the counter.
Rationale:
Conscientious programmers are forced now to write their own GENSYM
lookalikes because they know the system's GENSYM has an invasive
effect. This defeats the primary intended function of GENSYM, which
is to satisfy the most common idiomatic use of MAKE-SYMBOL.
The stickiness of the GENSYM prefix was an attempt to be gratuitously
compatible with Maclisp, at the expense of good programming pratice.
Users who need the old behavior of GENSYM can trivially implement
that behavior using MAKE-SYMBOL.
Occasionally you want to reset the GENSYM counter so that, for example,
you can get the compiler to generate the same symbol names again
(good for comparing results to see what really changed).
Test Case:
(CHAR-EQUAL (CHAR (SYMBOL-NAME (SECOND (LIST (GENSYM "A") (GENSYM)))) 0)
#\G)
=> NIL ;under CLtL
=> T ;under this proposal
(string= (symbol-name (progn (gensym-counter 43) (gensym "foo")))
"foo43") => T
Current Practice:
Symbolics Cloe and Genera are compatible with CLtL, so this would be an
incompatible change.
Cost to Implementors:
Very small.
Cost to Users:
Most uses of GENSYM do not depend on the stickiness of the name, so the
change would be compatible. In some cases, the change would be an
improvement. Even in the worst case where someone depends on stickiness,
it's extremely straightforward to write the couple of lines of code to
produce an application based on MAKE-SYMBOL that is at least as flexible
as GENSYM, and often moreso.
Cost of Non-Adoption:
Good programmers would avoid using the argument to GENSYM (or using
GENSYM altogether) in many situations where they ought not have to.
Benefits:
Gensyms which appear to convey information through their name would not
accidentally pop out and cause confusion in places where they oughtn't.
Aesthetics:
Unnecessary global state changes are hard to reason about. This would
be a small simplification.
Discussion:
Pitman claims to have written a non-sticky GENSYM function for nearly
every one of the dozen or so large systems that he's written or worked
on in the last decade in order to get around the stated problem.
Others have suggested similar experience.
Pitman supported version 1. In response to a query, he said:
"... the only part of this I really care about is that the name
not be sticky. If you make any reasonable counterproposal that gives
me that one feature, odds are that I'll support it."
Steele supports this proposal.
∂15-Mar-89 1449 CL-Cleanup-mailer Issue SUBTYPEP-TOO-VAGUE, version 5
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 14:46:57 PST
Received: from fafnir.think.com by Think.COM; Wed, 15 Mar 89 17:43:08 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 15 Mar 89 17:44:28 EST
Received: by verdi.think.com; Wed, 15 Mar 89 17:41:16 EST
Date: Wed, 15 Mar 89 17:41:16 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903152241.AA03730@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Subject: Issue SUBTYPEP-TOO-VAGUE, version 5
Cc: gls@Think.COM
This is a proposed amendment to version 4 passed in January 1989 at Kauai.
Issue: SUBTYPEP-TOO-VAGUE
References: CLtL p. 72-73
Category: CLARIFICATION
Edit History: Version 1, 11 Jul 1988 (Sandra Loosemore)
Version 2, 19 Jul 1988 (Sandra Loosemore)
Version 3, 6-Oct-88 (Masinter)
Version 4, 7-Oct-88 (Masinter, per Moon's comments)
Problem Description:
[From version 4]
The description of SUBTYPEP allows it to return a second value of NIL
when the relationship between the two types cannot be determined. In
some cases this is a reasonable thing to do because it is impossible
to tell (if the SATISFIES type specifier is involved), and in other
cases the relationships between types are not well-defined (for
example, the VALUES type specifier or the list form of the FUNCTION
type specifier).
Some implementations, however, have apparently interpreted this to
mean that it is permissible for SUBTYPEP to "give up" and return a
second value of NIL in some cases where it actually would be possible
to determine the relationship. This makes it difficult to depend on
subtype relationships in portable code.
[Addition for version 5]
There are two problems with version 4. First is that of the first three
bulleted points in the version 4 proposal:
* Clarify that SUBTYPEP will return a second value of NIL
only when either of the type specifiers involves the SATISFIES, NOT,
AND, OR, MEMBER. SUBTYPEP will not return a second
value of NIL when both arguments involve only the words in Table 4-1, or
names of DEFSTRUCT- or DEFCLASS-defined types, or user-defined deftypes
that expand into only those words and/or names.
* SUBTYPEP should signal an error when handed (for either argument)
a type specifier that involves VALUES or the list form of the FUNCTION
type.
* SUBTYPEP must always return values T T in the case where the two
type specifiers (or their expansions) are EQUAL.
any two have significant overlap, and indeed all three can overlap;
version 4 contained no indication of how this conflict should be resolved.
Second is that version 4 calls for SUBTYPEP to signal an error (at least at
high safety)even when the arguments are valid type specifiers, but this can
make it harder to use SUBTYPEP. These are cases that returning NIL NIL
was supposed to cover.
This version replaces the three bulleted points above with a single point
and some observations about its consequences. This version eliminates
the requirement to signal an error.
Proposal: SUBTYPEP-TOO-VAGUE:CLARIFY-MORE
A type specifier "involves" a word like SATISFIES, MEMBER, NOT, etc.
if it either contains it directly or as the result of expansion of a
DEFTYPE defined type specifier.
* Clarify that SUBTYPEP is permitted to return NIL NIL only when
at least one argument involves SATISFIES, AND, OR, NOT, MEMBER,
VALUES, or the list form of FUNCTION.
Note that one consequence of this is that if neither argument
involves any of these type specifiers, then SUBTYPEP is obliged
to determine the relationship accurately. In particular, SUBTYPEP
must return T T if the arguments are EQUAL and do not involve
any of the above-stated type specifiers.
* Clarify that the relationships between types reflected by SUBTYPEP
are those specific to the particular implementation. For example, if
an implementation supports only a single type of floating-point numbers,
in that implementation (SUBTYPEP 'FLOAT 'LONG-FLOAT) would return T T
(since the two types would be identical).
Rationale:
Specifying the behavior of SUBTYPEP makes it more useful. Otherwise,
programs cannot rely on any more than NIL NIL as return values.
It is generally conceded that it is impossible to determine the
relationships between types defined with the SATISFIES specifier.
MEMBER, AND, OR, and NOT are messy to deal with.
Current Practice:
The implementation of SUBTYPEP in (the original) HPCL does not try to
expand type specifiers defined with DEFTYPE and does not recognize
EQUAL type specifiers as being equivalent. Most other implementations
appear to be substantially in conformance with the proposal.
Cost to implementors:
Some implementations will have to rewrite and/or extend parts of SUBTYPEP.
Cost to users:
Its hard to imagine a portable program that depends heavily
on SUBTYPEP. This proposal does not require any implementation
to "handle" fewer cases of SUBTYPEP.
Benefits:
An area of confusion in the language is cleared up. Usages of SUBTYPEP
will be more portable.
Discussion:
The handling of FLOAT and SINGLE-FLOAT appeared to be the
consensus from a discussion on the common-lisp mailing list some
time ago.
It would not be too onerous to require implementations to handle
the cases where one but not the other type specifier involves
OR, AND, NOT or MEMBER, but the specification becomes
cumbersome.
A related issue is clarifying what kinds of type specifiers must be
recognized by functions such as MAKE-SEQUENCE and COERCE. For example,
HPCL complains that (SIMPLE-ARRAY (UNSIGNED-BYTE *) (*)) is not a valid
sequence type when passed to MAKE-SEQUENCE, although SUBTYPEP does
recognize it to be a subtype of SEQUENCE. Should this proposal be
extended to deal with these issues, or is another proposal in order?
The rules for comparing the various type specifiers (such as ARRAY)
need to be spelled out in detail.
∂15-Mar-89 1454 CL-Cleanup-mailer [gls: Issue SUBTYPEP-TOO-VAGUE, version 5]
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 14:50:43 PST
Received: from fafnir.think.com by Think.COM; Wed, 15 Mar 89 17:46:14 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 15 Mar 89 17:47:25 EST
Received: by verdi.think.com; Wed, 15 Mar 89 17:44:14 EST
Date: Wed, 15 Mar 89 17:44:14 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903152244.AA03741@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Subject: [gls: Issue SUBTYPEP-TOO-VAGUE, version 5]
[I forgot to update the edit history. Here is corrected copy.]
Date: Wed, 15 Mar 89 17:41:16 EST
From: Guy Steele <gls>
To: cl-cleanup@sail.stanford.edu
Subject: Issue SUBTYPEP-TOO-VAGUE, version 5
Cc: gls
This is a proposed amendment to version 4 passed in January 1989 at Kauai.
Issue: SUBTYPEP-TOO-VAGUE
References: CLtL p. 72-73
Category: CLARIFICATION
Edit History: Version 1, 11 Jul 1988 (Sandra Loosemore)
Version 2, 19 Jul 1988 (Sandra Loosemore)
Version 3, 6-Oct-88 (Masinter)
Version 4, 7-Oct-88 (Masinter, per Moon's comments)
Version 5, 15-Mar-89 Steele
Problem Description:
[From version 4]
The description of SUBTYPEP allows it to return a second value of NIL
when the relationship between the two types cannot be determined. In
some cases this is a reasonable thing to do because it is impossible
to tell (if the SATISFIES type specifier is involved), and in other
cases the relationships between types are not well-defined (for
example, the VALUES type specifier or the list form of the FUNCTION
type specifier).
Some implementations, however, have apparently interpreted this to
mean that it is permissible for SUBTYPEP to "give up" and return a
second value of NIL in some cases where it actually would be possible
to determine the relationship. This makes it difficult to depend on
subtype relationships in portable code.
[Addition for version 5]
There are two problems with version 4. First is that of the first three
bulleted points in the version 4 proposal:
* Clarify that SUBTYPEP will return a second value of NIL
only when either of the type specifiers involves the SATISFIES, NOT,
AND, OR, MEMBER. SUBTYPEP will not return a second
value of NIL when both arguments involve only the words in Table 4-1, or
names of DEFSTRUCT- or DEFCLASS-defined types, or user-defined deftypes
that expand into only those words and/or names.
* SUBTYPEP should signal an error when handed (for either argument)
a type specifier that involves VALUES or the list form of the FUNCTION
type.
* SUBTYPEP must always return values T T in the case where the two
type specifiers (or their expansions) are EQUAL.
any two have significant overlap, and indeed all three can overlap;
version 4 contained no indication of how this conflict should be resolved.
Second is that version 4 calls for SUBTYPEP to signal an error (at least at
high safety)even when the arguments are valid type specifiers, but this can
make it harder to use SUBTYPEP. These are cases that returning NIL NIL
was supposed to cover.
This version replaces the three bulleted points above with a single point
and some observations about its consequences. This version eliminates
the requirement to signal an error.
Proposal: SUBTYPEP-TOO-VAGUE:CLARIFY-MORE
A type specifier "involves" a word like SATISFIES, MEMBER, NOT, etc.
if it either contains it directly or as the result of expansion of a
DEFTYPE defined type specifier.
* Clarify that SUBTYPEP is permitted to return NIL NIL only when
at least one argument involves SATISFIES, AND, OR, NOT, MEMBER,
VALUES, or the list form of FUNCTION.
Note that one consequence of this is that if neither argument
involves any of these type specifiers, then SUBTYPEP is obliged
to determine the relationship accurately. In particular, SUBTYPEP
must return T T if the arguments are EQUAL and do not involve
any of the above-stated type specifiers.
* Clarify that the relationships between types reflected by SUBTYPEP
are those specific to the particular implementation. For example, if
an implementation supports only a single type of floating-point numbers,
in that implementation (SUBTYPEP 'FLOAT 'LONG-FLOAT) would return T T
(since the two types would be identical).
Rationale:
Specifying the behavior of SUBTYPEP makes it more useful. Otherwise,
programs cannot rely on any more than NIL NIL as return values.
It is generally conceded that it is impossible to determine the
relationships between types defined with the SATISFIES specifier.
MEMBER, AND, OR, and NOT are messy to deal with.
Current Practice:
The implementation of SUBTYPEP in (the original) HPCL does not try to
expand type specifiers defined with DEFTYPE and does not recognize
EQUAL type specifiers as being equivalent. Most other implementations
appear to be substantially in conformance with the proposal.
Cost to implementors:
Some implementations will have to rewrite and/or extend parts of SUBTYPEP.
Cost to users:
Its hard to imagine a portable program that depends heavily
on SUBTYPEP. This proposal does not require any implementation
to "handle" fewer cases of SUBTYPEP.
Benefits:
An area of confusion in the language is cleared up. Usages of SUBTYPEP
will be more portable.
Discussion:
The handling of FLOAT and SINGLE-FLOAT appeared to be the
consensus from a discussion on the common-lisp mailing list some
time ago.
It would not be too onerous to require implementations to handle
the cases where one but not the other type specifier involves
OR, AND, NOT or MEMBER, but the specification becomes
cumbersome.
A related issue is clarifying what kinds of type specifiers must be
recognized by functions such as MAKE-SEQUENCE and COERCE. For example,
HPCL complains that (SIMPLE-ARRAY (UNSIGNED-BYTE *) (*)) is not a valid
sequence type when passed to MAKE-SEQUENCE, although SUBTYPEP does
recognize it to be a subtype of SEQUENCE. Should this proposal be
extended to deal with these issues, or is another proposal in order?
The rules for comparing the various type specifiers (such as ARRAY)
need to be spelled out in detail.
∂15-Mar-89 1756 CL-Cleanup-mailer Re: Issue LOCALLY-TOP-LEVEL, v1
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 17:56:39 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAR 89 17:24:03 PST
Date: 15 Mar 89 17:23 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue LOCALLY-TOP-LEVEL, v1
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Mon, 13 Mar 89 18:51 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>, cl-cleanup@SAIL.STANFORD.EDU,
cl-compiler@SAIL.STANFORD.EDU
Message-ID: <890315-172403-1288@Xerox>
I don't care what committee you send it to, but since Sandra has already
finished her list of proposals and I'm still working on mine, you might as
well get it on mine. Cleanup has more time, anyway.
It looked like it only needed the minor edit to fix the NO-HOSTING
allusion.
∂15-Mar-89 1907 CL-Cleanup-mailer Re: Issue STREAM-ACCESS
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 19:06:57 PST
Received: from Semillon.ms by ArpaGateway.ms ; 15 MAR 89 18:33:15 PST
Date: 15 Mar 89 18:31 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue STREAM-ACCESS
In-reply-to: Kim A. Barrett <IIM@ECLA.USC.EDU>'s message of Fri, 10 Mar 89
14:41:53 PST
To: Kim A. Barrett <IIM@ECLA.USC.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <890315-183315-1621@Xerox>
I don't think we want either
(typecase stream
(two-way-stream ...)
(echo-stream ...)
to behave in an implementation-dependent manner, or
to require that echo-stream be a subtype of two-way-stream.
You can always have a class that is their mutual
superclass, i.e., that they both inherit from.
However, the relation between the streams in
echo and two-way is significantly different.
∂16-Mar-89 0523 CL-Cleanup-mailer Re: Issue: GENSYM-NAME-STICKINESS, version 2
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 16 Mar 89 05:23:07 PST
Received: from relay2.cs.net by RELAY.CS.NET id ab00401; 16 Mar 89 8:13 EST
Received: from draper.com by RELAY.CS.NET id aa08495; 16 Mar 89 8:10 EST
Date: Thu, 16 Mar 89 07:58 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Issue: GENSYM-NAME-STICKINESS, version 2
To: cl-cleanup@SAIL.STANFORD.EDU
X-VMS-To: CL-CLEANUP,SEB1525
I like it. But one suggestion:
Instead of (gensym-counter <n>) which updates the gensym counter, why not
(gensym-counter) which returns the current gensym counter, and
(setf (gensym-counter) <n>) ???
∂16-Mar-89 0646 CL-Cleanup-mailer Issue: GENSYM-NAME-STICKINESS, version 2
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 06:46:44 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558309; Thu 16-Mar-89 09:44:17 EST
Date: Thu, 16 Mar 89 09:44 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: GENSYM-NAME-STICKINESS, version 2
To: GLS@Think.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890316094401.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Can you motivate why you want a function rather than a variable
for the counter control? For example, a useful feature of a
variable would be to bind it.
My basic feeling is that if we need a function rather than variable,
we must need the function for a reason. What is the function providing
that is worth the added descriptive overhead and loss of (binding)
flexibility but that is not stated in the writeup?
∂16-Mar-89 0807 CL-Cleanup-mailer Re: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 16 Mar 89 08:06:57 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA02088; Thu, 16 Mar 89 11:04:37 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA07042; Thu, 16 Mar 89 10:41:17 EST
Message-Id: <8903161541.AA07042@mist.>
To: CL-CLEANUP@Sail.stanford.edu
Subject: Re: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)
In-Reply-To: Your message of 15 Mar 89 17:16:00 -0800.
<890315-171714-1269@Xerox>
Date: Thu, 16 Mar 89 10:41:15 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Sorry for the late reply on this.
The only problem with this proposal is that *BREAK-ON-SIGNALS* seems
to implicitly depend on either:
1. Having all condition types you want to control in one inheritance
tree.
2. Or SUBTYPEP supporting MEMBER type specifiers.
For example, suppose you create a new subtype of CONDITION, disjoint
from WARNING, called FROB, that does not break by default. Now
suppose you want to break on both WARNING and FROB, but not on another
disjoint subtype of CONDITION, say BLAT. The only way I can see to do
this would be:
(SETQ *BREAK-ON-SIGNALS* '(MEMBER WARNING FROB))
But this would presumably fail to work in an implementation that
compilied minimally with SUBTYPEP-TOO-VAGUE.
Of course, *BREAK-ON-WARNINGS* doesn't solve this problem, it just
dodges the one occurance of it that involves standard condition types.
∂16-Mar-89 0827 CL-Cleanup-mailer Re: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 16 Mar 89 08:26:55 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA02401; Thu, 16 Mar 89 11:24:37 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA07142; Thu, 16 Mar 89 11:22:55 EST
Message-Id: <8903161622.AA07142@mist.>
Cc: CL-CLEANUP@Sail.stanford.edu
Subject: Re: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)
In-Reply-To: Your message of Thu, 16 Mar 89 10:41:15 -0500.
<8903161541.AA07042@mist.>
Date: Thu, 16 Mar 89 11:22:50 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Oops, braino. The previous version of this message used MEMBER when I
meant OR. Here is a corrected version:
Sorry for the late reply on this.
The only problem with this proposal is that *BREAK-ON-SIGNALS* seems
to implicitly depend on either:
1. Having all condition types you want to control in one inheritance
tree, or
2. SUBTYPEP supporting OR type specifiers.
For example, suppose you create a new subtype of CONDITION, disjoint
from WARNING, called FROB, that does not break by default. Now
suppose you want to break on both WARNING and FROB, but not on another
disjoint subtype of CONDITION, say BLAT. The only way I can see to do
this would be:
(SETQ *BREAK-ON-SIGNALS* '(OR WARNING FROB))
But this would presumably fail to work in an implementation that
compilied minimally with SUBTYPEP-TOO-VAGUE.
Of course, *BREAK-ON-WARNINGS* doesn't solve this problem, it just
dodges the one occurance of it that involves standard condition types.
∂16-Mar-89 0831 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 08:31:50 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 08:27:48 PST
Date: 16 Mar 89 08:27 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue PROCLAIM-LEXICAL (Version 9)
In-reply-to: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>'s
message of Wed, 15 Mar 89 20:10:25 GMT
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
cc: masinter.pa@Xerox.COM, cl-cleanup@sail.stanford.edu
Message-ID: <890316-082748-3893@Xerox>
Does anyone at least have a record of the amendments that were proposed at
the last meeting. In lieu of a new version, we are probably obligated to
put version 9, as amended, on the table.
∂16-Mar-89 0917 CL-Cleanup-mailer Issue LOOP-AND-DISCREPANCY, version 1
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 09:17:31 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558503; Thu 16-Mar-89 12:15:07 EST
Date: Thu, 16 Mar 89 12:15 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue LOOP-AND-DISCREPANCY, version 1
To: Guy Steele <gls@Think.COM>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8903151850.AA02865@verdi.think.com>
Message-ID: <19890316171508.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
I like LOOP-AND-DISCREPANCY:NO-REITERATION.
∂16-Mar-89 0932 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL (Version 9)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 09:32:12 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558521; Thu 16-Mar-89 12:29:32 EST
Date: Thu, 16 Mar 89 12:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue PROCLAIM-LEXICAL (Version 9)
To: masinter.pa@Xerox.COM
cc: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, cl-cleanup@sail.stanford.edu
In-Reply-To: <890316-082748-3893@Xerox>
Message-ID: <19890316172923.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 16 Mar 89 08:27 PST
From: masinter.pa@Xerox.COM
Does anyone at least have a record of the amendments that were proposed at
the last meeting. In lieu of a new version, we are probably obligated to
put version 9, as amended, on the table.
Maybe I shouldn't take this attitude, but I will anyway. I have brief
notes on the amendments that were proposed, but since I think all of them
were wrongheaded and braindamaged, I'm not going to help anyone remember
them. Only one of the amendments was actually voted on, so we're certainly
free to forget the other two.
∂16-Mar-89 1044 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 10:44:44 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 10:26:03 PST
Date: 16 Mar 89 10:02 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue PROCLAIM-LEXICAL (Version 9)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Thu, 16 Mar 89 12:29 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: masinter.pa@Xerox.COM, Jeff Dalton
<jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, cl-cleanup@sail.stanford.edu
Message-ID: <890316-102603-4543@Xerox>
What I meant to ask was: what amendments actually passed? If none, then we
can just bring up version 9 again. I think we can certainly ignore
amendments that were were voted on and failed or did not come far enough to
get to a vote.
∂16-Mar-89 1115 CL-Cleanup-mailer Issue: GENSYM-NAME-STICKINESS, version 2
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 11:15:10 PST
Received: from fafnir.think.com by Think.COM; Thu, 16 Mar 89 13:52:43 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Thu, 16 Mar 89 13:53:38 EST
Received: by verdi.think.com; Thu, 16 Mar 89 13:50:26 EST
Date: Thu, 16 Mar 89 13:50:26 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903161850.AA04888@verdi.think.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: GLS@Think.COM, CL-Cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Thu, 16 Mar 89 09:44 EST <890316094401.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: GENSYM-NAME-STICKINESS, version 2
Date: Thu, 16 Mar 89 09:44 EST
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Can you motivate why you want a function rather than a variable
for the counter control? For example, a useful feature of a
variable would be to bind it.
My basic feeling is that if we need a function rather than variable,
we must need the function for a reason. What is the function providing
that is worth the added descriptive overhead and loss of (binding)
flexibility but that is not stated in the writeup?
So that at the time the counter is changed I can convert it to
packed decimal on a VAX and use string instructions.
Seriously, I had in mind doing error-checking at counter-setting time
and thus avoiding questions of what happens when if you supply a bogus
counter value.
But if that is not worth it, then I will settle for a variable.
--Guy
∂16-Mar-89 1143 CL-Cleanup-mailer Re: DRAFT Issue: CONDITION-RESTARTS (Version 1)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Mar 89 11:42:54 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA02340; Thu, 16 Mar 89 12:39:36 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA05919; Thu, 16 Mar 89 12:39:34 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903161939.AA05919@defun.utah.edu>
Date: Thu, 16 Mar 89 12:39:32 MST
Subject: Re: DRAFT Issue: CONDITION-RESTARTS (Version 1)
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@SAIL.Stanford.EDU
In-Reply-To: masinter.pa@Xerox.COM, 16 Mar 89 10:24 PST
This issue impacts the cl-compiler issue COMPILER-DIAGNOSTICS. The
current proposal we have on that issue requires COMPILE-FILE to establish
a condition handler that resignals conditions. Obviously we have a
problem if resignalling is forbidden.
-Sandra
-------
∂16-Mar-89 1234 CL-Cleanup-mailer Re: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 12:34:03 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558776; Thu 16-Mar-89 15:30:56 EST
Date: Thu, 16 Mar 89 15:30 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)
To: Dan L. Pierson <pierson@mist.encore.com>
cc: CL-CLEANUP@Sail.stanford.edu
In-Reply-To: <8903161622.AA07142@mist.>
Message-ID: <19890316203057.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 16 Mar 89 11:22:50 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Oops, braino. The previous version of this message used MEMBER when I
meant OR. Here is a corrected version:
Sorry for the late reply on this.
The only problem with this proposal is that *BREAK-ON-SIGNALS* seems
to implicitly depend on either:
1. Having all condition types you want to control in one inheritance
tree, or
2. SUBTYPEP supporting OR type specifiers.
For example, suppose you create a new subtype of CONDITION, disjoint
from WARNING, called FROB, that does not break by default. Now
suppose you want to break on both WARNING and FROB, but not on another
disjoint subtype of CONDITION, say BLAT. The only way I can see to do
this would be:
(SETQ *BREAK-ON-SIGNALS* '(OR WARNING FROB))
But this would presumably fail to work in an implementation that
compilied minimally with SUBTYPEP-TOO-VAGUE.
I don't believe this is a real problem, because the signaller has a
condition object in its hand, so it would be calling TYPEP, not SUBTYPEP.
TYPEP has no problems working with OR.
In fact SUBTYPEP has no problems working with OR as the second argument,
so you have also pointed out a bug in SUBTYPEP-TOO-VAGUE; it should not
allow SUBTYPEP to fail when just the second argument involves OR. I think
this has been pointed out before.
∂16-Mar-89 1252 CL-Cleanup-mailer DEFAULT-CASE
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 89 12:52:43 PST
Received: from franz.UUCP by ucbarpa.Berkeley.EDU (5.61/1.33)
id AA18242; Thu, 16 Mar 89 12:24:16 -0800
Received: from frisky by franz (3.2/3.14)
id AA21310; Thu, 16 Mar 89 12:23:04 PST
Received: by frisky (3.2/3.14)
id AA08568; Thu, 16 Mar 89 12:21:59 PST
From: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
Return-Path: <frisky!jkf>
Message-Id: <8903162021.AA08568@frisky>
To: franz!sail.stanford.edu!CL-Cleanup
Subject: DEFAULT-CASE
Date: Thu, 16 Mar 89 12:21:57 PST
I brought up the issue of case-sensitive programming a few weeks
ago and there was no negative mail. My message was part of the
discussion on the READ-CASE-SENSITIVITY issue but in thinking it over
I believe that it makes more sense to look at what is needed to make
Common Lisp more useful in case-sensitive environments as two
separate things: 1. allow to the reader to be case-sensitive, and
2. make the names be lower-case by default. Item 1 is already being
worked on, here is item 2:
john foderaro
franz inc.
jkf%franz.uucp@berkeley.edu
Issue: DEFAULT-CASE
Forum: Cleanup
References: CLtL p 334 ff: What the Read Function Accepts;
especially p 337.
Issue: READ-CASE-SENSITIVITY
Category: CHANGE
Edit History: 16-Mar-89, Version 1 by jkf
Problem Description:
In most programming/operating-system environments where the case
of names of functions, programs, identifiers, and files *does*
matter, the case of most characters used for such purposes
is lower case. One example of such an environment is the Unix
operating system.
The resolution of the READ-CASE-SENSITIVITY will permit
one to write case-sensitive Lisp code however since the
the case of characters in the print names of all standard
functions and symbols is upper, this will make using
the Lisp in a case-sensitive mode difficult.
Proposal (DEFAULT-CASE:LOWER)
The case of all characters in the names of standard
functions, symbols, and packages is lower.
Rationale:
People running in a case-insensitive mode shouldn't care
which case is the default case.
People running in a case-sensitive mode care very much
which case is default, and for most of these people
lower case is preferred.
Furthermore there are a large number of users
of Lisp in case-sensitive environments and it is important
that the desires of these users be met.
Current Practice:
Franz Inc's Allegro Common Lisp supports a case-sensitive
reader with either a upper-case default for names
or a lower-case default. A number of people use the
case-sensitive feature with a lower-case default. I don't
know anyone that uses the lisp in a case-sensitive mode
with an upper-case default.
Cost to Implementors:
In case-insensitive mode, the cost to make characters downcase
rather than upcase should be small.
The cost of locating and fixing all of the places where
the default case of symbol names actually matters will be moderate
(I suspect that the older the Lisp the more numerous
the instances of dependency on the case of the names).
Cost to Users:
Again, the cost of locating and fixing all of the places where
the default case of symbol names actually matters will be moderate.
As an example, to find and fix all of the places in the PCL
source (~15000 lines) that depend on the default case took
me 15 minutes.
Cost of Non-Adoption:
Using Lisp in case-sensitive environments will continue to be
awkward.
It will continue to be hard for Lisp to interact
with programs written in case-sensitive languages (such as C).
The use of case sensitivity as a tool for writing programs
will continue to be unavailable to Lisp programmers.
Vendors will invent their own methods of adding case-sensitivity,
each in their own different way.
Benefits:
See 'Cost of Non-Adoption'.
Aesthetics:
Most Lisp books (including CLtL) put Lisp code in lower case.
I believe that most people prefer to read text written in lower case.
Discussion:
The best solution would be for there to be a way to make the
reader case-sensitive (i.e. a resolution to the READ-CASE-SENSITIVITY
issue) and for DEFAULT-CASE:LOWER to pass. If for some
reason the READ-CASE-SENSITIVITY should not be resolved in
a manner that results in a case-sensitive reader option, it would
still be good to pass DEFAULT-CASE:LOWER since that would
bring Common Lisp one giant step closer to supporting the
case-sensitive environment.
-------------------------------
∂16-Mar-89 1318 CL-Cleanup-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 13:18:12 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558836; Thu 16-Mar-89 16:11:38 EST
Date: Thu, 16 Mar 89 16:11 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)
To: Barry Margolin <barmar@FAFNIR.THINK.COM>
cc: masinter.pa@xerox.com, kmp@symbolics.com, cl-cleanup@sail.stanford.edu
In-Reply-To: <19890315185842.5.BARMAR@OCCAM.THINK.COM>
Message-ID: <19890316211129.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
I don't have the mail message you referred to ("I suggest that the text
Amemdment I from my 14 February mail be used verbatim as the proposal.").
However, I like the way you dealt with NCONC in version 5, I don't
see any need for a separate proposal.
Generally this looks okay. I thought you were going to remove this:
(NSUBSTITUTE new-object old-object sequence ...)
(NSUBSTITUTE-IF new-object test sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure in that sequence.
when sequence is an array is permitted to SETF the contents of
any cell in that array which must be replaced by NEW-OBJECT.
since in fact there is no need to give NSUBSTITUTE the freedom
to modify anything more than what it is required to modify. I
still think it should be removed, just as NSUBST was removed.
∂16-Mar-89 1338 CL-Cleanup-mailer Issue: ENVIRONMENT-ENQUIRY (not submitted)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 13:38:11 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 13:17:03 PST
Date: 16 Mar 89 13:16 PST
From: masinter.pa@Xerox.COM
Subject: Issue: ENVIRONMENT-ENQUIRY (not submitted)
To: cl-cleanup@sail.stanford.edu
Message-ID: <890316-131703-5387@Xerox>
I had this on my status list:
* ENVIRONMENT-ENQUIRY
Synopsis: "The environment inquiry functions (pp447-448) don't return a
value in consistent format across implementations. This makes
them virtually useless. I would like to constrain the values
enough so that implementors knew what to provide as return
values, and provide some examples of intended uses."
Status: need volunteer to submit
I don't have much to say on this issue and cannot find message from which I
excerpted the quote. Who is the "I" here? Do you want to submit a proposal?
∂16-Mar-89 1338 CL-Cleanup-mailer Re: Issue EQUALP-GENERIC
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 13:38:24 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 13:23:03 PST
Date: 16 Mar 89 13:22 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue EQUALP-GENERIC
In-reply-to: Kim A. Barrett <IIM@ECLA.USC.EDU>'s message of Thu, 9 Mar 89
23:11:34 PST
To: Kim A. Barrett <IIM@ECLA.USC.EDU>
cc: Moon@SCRC-STONY-BROOK.ARPA, cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <890316-132303-5408@Xerox>
I didn't think this was ready for release. Will there be a new version very soon?
∂16-Mar-89 1440 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL (Version 9)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 14:40:07 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558955; Thu 16-Mar-89 17:36:38 EST
Date: Thu, 16 Mar 89 17:36 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue PROCLAIM-LEXICAL (Version 9)
To: masinter.pa@Xerox.COM
cc: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, cl-cleanup@sail.stanford.edu
In-Reply-To: <890316-102603-4543@Xerox>
Message-ID: <19890316223630.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 16 Mar 89 10:02 PST
From: masinter.pa@Xerox.COM
What I meant to ask was: what amendments actually passed?
One amendment actually passed, but I'm still going to be a jerk and not
tell you what it was. If someone wants to propose the same amendment
again, I don't think that will waste very much time.
∂16-Mar-89 1518 CL-Cleanup-mailer DEFAULT-CASE
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 15:18:13 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 559010; Thu 16-Mar-89 18:15:06 EST
Date: Thu, 16 Mar 89 18:15 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DEFAULT-CASE
To: John Foderaro <franz!frisky!jkf@ucbarpa.Berkeley.EDU>
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <8903162021.AA08568@frisky>
Message-ID: <19890316231500.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Proposal (DEFAULT-CASE:LOWER)
The case of all characters in the names of standard
functions, symbols, and packages is lower.
You're proposing a huge incompatible change that is bound to
get you into a religious war that can't do anyone any good.
I claim that this proposal addresses the internal representation
of programs but all you care about is the external representation.
I also claim that the choice of case in internal representation
is arbitrary and need not prejudice the external representation
at all.
If you believe what I just said, you would propose that the reader get
an option to flip case instead of up-casing when converting from
external representation to internal representation, and would propose
another value for *print-case* that does the inverse transformation.
This would be compatible with everybody, would make everybody happy
except for those who might insist that one internal representation
is better than the other, and hopefully would avoid spending a lot
of time on discussion. What do you think?
∂16-Mar-89 1555 CL-Cleanup-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 15:54:23 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Thu, 16 Mar 89 17:24:17 EST
Date: Thu, 16 Mar 89 17:22 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: masinter.pa@xerox.com, kmp@symbolics.com, cl-cleanup@sail.stanford.edu
In-Reply-To: <19890316211129.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <19890316222229.3.BARMAR@OCCAM.THINK.COM>
Date: Thu, 16 Mar 89 16:11 EST
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
I don't have the mail message you referred to ("I suggest that the text
Amemdment I from my 14 February mail be used verbatim as the proposal.").
However, I like the way you dealt with NCONC in version 5, I don't
see any need for a separate proposal.
Generally this looks okay. I thought you were going to remove this:
(NSUBSTITUTE new-object old-object sequence ...)
(NSUBSTITUTE-IF new-object test sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure in that sequence.
when sequence is an array is permitted to SETF the contents of
any cell in that array which must be replaced by NEW-OBJECT.
since in fact there is no need to give NSUBSTITUTE the freedom
to modify anything more than what it is required to modify. I
still think it should be removed, just as NSUBST was removed.
I think I remember my reason (it's been a month since I wrote the
amendment). I removed NSUBST because CLtL was already very specific
about what it does. CLtL's description of NSUBSTITUTE isn't very
specific; removing it from the proposal would just leave it implicitly
vague instead of making it explicitly vague, and I'd prefer to be
explicit.
I would support a version that makes NSUBSTITUTE* be explicitly
specific. I see no reason not to require it to use SETF of CAR or AREF,
as appropriate. Unless someone is working on CAR-coding, I don't think
it precludes any known optimizations.
barmar
∂16-Mar-89 1605 CL-Cleanup-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 16:05:44 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 559069; Thu 16-Mar-89 19:02:17 EST
Date: Thu, 16 Mar 89 19:02 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)
To: Barry Margolin <barmar@Think.COM>
cc: masinter.pa@xerox.com, kmp@symbolics.com, cl-cleanup@sail.stanford.edu
In-Reply-To: <19890316222229.3.BARMAR@OCCAM.THINK.COM>
Message-ID: <19890317000217.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Thu, 16 Mar 89 17:22 EST
From: Barry Margolin <barmar@Think.COM>
Date: Thu, 16 Mar 89 16:11 EST
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
I don't have the mail message you referred to ("I suggest that the text
Amemdment I from my 14 February mail be used verbatim as the proposal.").
However, I like the way you dealt with NCONC in version 5, I don't
see any need for a separate proposal.
Generally this looks okay. I thought you were going to remove this:
(NSUBSTITUTE new-object old-object sequence ...)
(NSUBSTITUTE-IF new-object test sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure in that sequence.
when sequence is an array is permitted to SETF the contents of
any cell in that array which must be replaced by NEW-OBJECT.
since in fact there is no need to give NSUBSTITUTE the freedom
to modify anything more than what it is required to modify. I
still think it should be removed, just as NSUBST was removed.
I think I remember my reason (it's been a month since I wrote the
amendment). I removed NSUBST because CLtL was already very specific
about what it does. CLtL's description of NSUBSTITUTE isn't very
specific; removing it from the proposal would just leave it implicitly
vague instead of making it explicitly vague, and I'd prefer to be
explicit.
I see.
I would support a version that makes NSUBSTITUTE* be explicitly
specific. I see no reason not to require it to use SETF of CAR or AREF,
as appropriate. Unless someone is working on CAR-coding, I don't think
it precludes any known optimizations.
I'd support that too. In other words, describe NSUBSTITUTE with language
similar to the description of NSUBST.
∂16-Mar-89 1802 CL-Cleanup-mailer Issue: TYPE-OF-UNDERCONSTRAINED, v.5
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 18:02:00 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 17:54:51 PST
Date: 16 Mar 89 17:40 PST
From: masinter.pa@Xerox.COM
To: cl-cleanup@sail.stanford.edu
Subject: Issue: TYPE-OF-UNDERCONSTRAINED, v.5
Message-ID: <890316-175451-6328@Xerox>
I think Guy missed a couple of the amendments that passed
at the last meeting. This is what I started to send out
to X3J13, but since I've tried to "patch" the wording a bit
since it seems that some of the constraints put on TYPE-OF
by this proposal are overlapping, I thought I would send
it to cl-cleanup first. (Since this was raised at the last
meeting, there's not a problem about the 'two-week' rule,
I think.)
Version 3 of this proposal was raised at the January 1989
X3J13, and passed with three amendments:
a) add RANDOM-STATE to the list of types
b) add the requirement that TYPE-OF is a subtype of CLASS-OF
c) change the relation to CLOS to say
"for all objects
for which CLASS-OF returns a class with a proper name, TYPE-OF returns
that proper name."
It was noted that SHORT-FLOAT, LONG-FLOAT and RATIONAL were
omitted inadvertently. We would like to ask that the proposal
be reconsidered so that these types could also be included.
This version includes those amendments, and also
adds SHORT-FLOAT, LONG-FLOAT, and RATIONAL
to the list of types in part (a) of the proposal.
!
Forum: Cleanup
Issue: TYPE-OF-UNDERCONSTRAINED
References: TYPE-OF (CLtL)
88-002R (Class-of)
88-005, p 43f, Condition system types
Related issues: SUBTYPEP-TOO-VAGUE
DATA-TYPE-HIERARCHY-UNDERSPECIFIED
FUNCTION-TYPE
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
COERCE-INCOMPLETE
Category: CLARIFICATION/CHANGE
Edit history: Version 1, 1-Dec-88, Masinter
Version 2, 9-Dec-88, Masinter
Version 3, 12-Dec-88, Masinter (fix "egregious bug")
Version 4, 3-14-89 Steele
Version 5, 16-Mar-89, Masinter (add other amendments)
Problem description:
The specification of TYPE-OF in CLtL is so weak as to leave it
nearly useless, if any implementor actually took the specification
seriously.In particular, there are almost no constraints on the
value that TYPE-OF might return for any of the built in
types. The only constraint placed is that for objects created by the
constructor function of DEFSTRUCT, the result of TYPE-OF is the name of the
defstruct.
This means that implementations could return T for all other objects.
Proposal (TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS):
Specify that the result of TYPE-OF satisfies the following:
(a) For any object for which (typep object built-in-type) is true when
built-in-type is one of
INTEGER, RATIO, FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, COMPLEX, NUMBER,
SYMBOL,
STRING, VECTOR, ARRAY, RANDOM-STATE,
CONS,
STREAM, PACKAGE, CHARACTER, FUNCTION, READTABLE, HASH-TABLE, PATHNAME,
CONDITION, RESTART,
RATIONAL, SHORT-FLOAT, LONG-FLOAT
the result of TYPE-OF will be a type specifier for which
(subtypep (type-of object) built-in-type) returns T T, i.e., either the
build-in-type or a subtype of it (a subtype that the
implementation's SUBTYPEP can recognize.)
(b) For all objects, (TYPEP object (TYPE-OF object)) will be true.
(this implies that it will not be NIL, since no
object is of type NIL.)
(c) will not be a MEMBER type specifier, or T.
The type returned by TYPE-OF is always a subtype of the class
returned by CLASS-OF.
For all objects for which CLASS-OF returns a class with a proper name,
TYPE-OF returns that proper name.
In particular, for objects created by the "constructor" function
of a structure defined with DEFSTRUCT without a :TYPE option,
TYPE-OF will return the structure name.
For all objects for which (CLASS-NAME (CLASS-OF object)) is NIL),
the result of TYPE-OF will return the class object itself.
(The CLOS specification has already specified that class objects are
acceptable wherever type specifiers are, and in particular, as input to
SUBTYPEP and TYPEP.)
This proposal is intended to be consistent with 88-002R,
and not to conflict with any of the definitions in that document.
Examples:
It is legal for (TYPE-OF "abc") to return (SIMPLE-STRING 3), or just
STRING. It is legal for (TYPE-OF 112312) to return SI:MEDIUM-SIZE-FIXNUM,
as long as (SUBTYPEP 'SI:MEDIUM-SIZE-FIXNUM 'INTEGER).
Given:
(defvar *foo* (make-array 5 :element-type t))
(class-name (class-of *foo*)) => SIMPLE-VECTOR
It is legal for
(type-of *foo*) => (SIMPLE-VECTOR 5)
Rationale:
The original specification for "TYPE-OF" was written to allow
implementation freedom, but the wording is in fact more vague than was
intended.
Current practice:
Most Common Lisp implementations seem to implement the proposal, at least
for the types we've tried them on.
Cost to Implementors:
Even if there are implementations that do not currently implement the
proposal, the required changes for them are likely to be minimal.
Cost to Users:
Apparently none.
Cost of non-adoption:
TYPE-OF would remain potentially inconsistent.
Performance impact:
Likely none.
Benefits:
Bring the specification of TYPE-OF in like with its common
implementation, while requiring it to be generally useful.
Esthetics:
Little effect.
Discussion:
Originally, TYPE-OF was concieved as being useful for information display.
CLOS specified CLASS-OF far more precisely, in that it must return exactly
the class of an object. Unless TYPE-OF is removed from the language, it
seems reasonable to require it to be at least as precise as CLASS-OF.
The accepted CLOS specification does not define CLASS-OF
in terms of TYPE-OF, but an earlier draft did.
This proposal presumes the (passed) proposals
DATA-TYPES-HIERARCHY-UNDERSPECIFIED:DISJOINT, FUNCTION-TYPE, and
accomodates the Condition System (version 18) and CLOS.
If ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS does not pass,
and this proposal does pass, it may be that the only way an
implementation can satisfy (TYPEP array (TYPE-OF array))
would be to have (TYPE-OF array) return VECTOR or ARRAY
as appropriate, i.e., with no element type qualification.
It is possible to constrain TYPE-OF further, e.g., to eliminate
the possibility that it might return a non-portable
implementation-specific value. For example,
(TYPE-OF 112312) should not return SI:MEDIUM-SIZE-FIXNUM, but rather some
thing like (SIGNED-BYTE 17) [if that's what SI:MEDIUM-SIZE-FIXNUM means.]
We would like to make this as an implementation recommendation,
however, rather than as a constraint, at this point.
----- End Forwarded Messages -----
∂16-Mar-89 2116 CL-Cleanup-mailer Re: Issue: EXPT-ZERO-ZERO (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 21:16:33 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 21:10:42 PST
Date: 16 Mar 89 21:10 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: EXPT-ZERO-ZERO (Version 1)
To: KMP@symbolics.com, CL-Cleanup@sail.stanford.edu,
Cyphers@jasper.scrc.symbolics.com
Message-ID: <890316-211042-6708@Xerox>
Kent, do you want to proceed with this one? I don't think it is necessary
or even a good idea. What do other programming languages do?
If you do, I think we should leave (EXPT 0 0) = 1 and (EXPT 0.0 0) = 1 and
only deal with (EXPT 0.0 0.0) and (EXPT 0 0.0).
Doesn't this fit into the ERRORS-IN-NUMBERS-CHAPTER spectrum?
∂16-Mar-89 2212 CL-Cleanup-mailer Issue: FIXNUM-NON-PORTABLE, v.5
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 22:11:59 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 22:09:33 PST
Date: 16 Mar 89 21:51 PST
From: masinter.pa@Xerox.COM
to: cl-cleanup@sail.stanford.edu
Subject: Issue: FIXNUM-NON-PORTABLE, v.5
line-fold: NO
Message-ID: <890316-220933-6804@Xerox>
This is my rewrite to capture the 'intent' of the amendment
at the January X3J13. I say 'intent' because the relation
between MOST-POSITIVE-FIXNUM (which is an inclusive bound)
and ARRAY-DIMENSION-LIMIT (which is an exclusive bound) is not
> but rather (>= MOST-POSITIVE-FIXNUM (1- ARRAY-DIMENSION-LIMIT)).
A minor nit. I wonder if we need to bring copies of the issues
that were passed at the last meeting for the 'approval of
the minutes' part.
!
Status: Passed Jan 89 X3J13, as amended
Issue: FIXNUM-NON-PORTABLE
References: CLtL p. 14, 34, 43, 231
Category: CHANGE, CLARIFICATION
Edit History: Version 1, 11-Jul-88, Sandra Loosemore
Version 2, 15-Sep-88, Masinter
Version 3, 23-Sep-88, Masinter
Version 4, 7-Dec-88, Masinter (two proposals)
Version 5, 16-Mar-89, Masinter (incorporate amendments)
Problem Description:
Implementations of Common Lisp are required to support two disjoint
subsets of integers, fixnums and bignums, with the promise that
fixnums have a more efficient representation. However, nothing is
guaranteed about the range of integers which are fixnums: "Exactly
which integers are fixnums is implementation-dependent; typically they
will be those integers in the range -2**n to 2**n - 1, inclusive, for
some n not less than 15."
There are few uses of the fixnum type that are portable, given the
current definition. In particular, many programmers use FIXNUM type
declarations where they really mean "small integer".
While most Common Lisp implementations have a FIXNUM range
which is a subset of integers represeted and operated on most
efficiently, many also have several other subranges. The
partitioning of INTEGER into BIGNUM and FIXNUM is merely
confusing in these implementations, and not useful.
CLtL p14 and p34 disagree about BIGNUM. One says that
FIXNUM and BIGNUM are an exhaustive partition of the
integer space, the other says they might not be!
Proposal: FIXNUM-NONPORTABLE:TIGHTEN-DEFINITION
(1) Change the description of the type FIXNUM to reflect that it is
required to be a supertype of (SIGNED-BYTE 16).
(2) Define BIGNUM to be exactly (AND INTEGER (NOT FIXNUM))
(3) require that MOST-POSITIVE-FIXNUM be large enough
to hold all array indices, i.e.,
(>= MOST-POSITIVE-FIXNUM (1- ARRAY-DIMENSION-LIMIT))
Example:
Consider an implementation with three numeric representations:
Fast (INTEGER -1024 1023)
Immediate 29 bits
Extended Multi-precision
Such an implementation would have to define
FIXNUM to be (OR Fast Immediate). BIGNUM
would then refer to multi-precision integers.
Rationale:
Many programmers already use FIXNUM to mean "small integer"; this
proposal makes this usage portable.
However, there is little portable use for the type BIGNUM, and it
is inconsistent with many current implementation techniques.
Removing it is an incompatible change for a weak reason.
Current Practice:
Xerox Common Lisp has 17-bit fixnums. Most other Common Lisp
implementations have fixnum ranges of 24 bits or larger. We know
of no implementation that currently violates the proposed minimum
size.
Several existing Common Lisp implementations have more than two
representations for integers, such that the FIXNUM/BIGNUM distinction
is confusing; they define BIGNUM to cover all of the larger number
types.
Cost to implementors:
Slight. All implementations we know of already define FIXNUMs to be at
least 16 bits.
Cost to users:
Slight.
Benefits:
The FIXNUM type specifier would have a portable interpretation.
The language would be less confusing.
Discussion:
There was little consensus on whether to leave BIGNUM in the language.
Earlier discussion of a related proposal contained several other more controversial
components (adding a constant MAX-INTEGER-LENGTH, allowing
MOST-POSITIVE-FIXNUM to be NIL as well as an integer.) This proposal
is an attempt to address the part that cleanup committee seemed to agree on.
It is possible that an implementation have a single representation for all
integers, and no way to identify any efficient range of integers. Those
implementations might need to set MOST-POSITIVE-FIXNUM
and MOST-NEGATIVE-FIXNUM to arbitrary values, consistent with
the requirement that (SIGNED-BYTE 16) is a subtype of FIXNUM.
Other alternatives considered (and not necessarily mutually exclusive
with this proposal):
remove the FIXNUM type specifier entirely, while leaving a way
to query what is the most efficient range of integers
leave the range of FIXNUMs unconstrained and introduce a
SMALL-INTEGER type with a fixed range (but no promises about
efficiency) .
It might be possible to specify the required performance behavior
of FIXNUMs more concretely, e.g., specify that the basic integer operations
use algorithms that are not proportional to the size of the data; it
should be just about as fast to add numbers in the middle of the fixnum
range as it is to add, say, 10 and 11. This might be a useful way to describe
the intent of the FIXNUM range, if not its specification.
∂16-Mar-89 2253 CL-Cleanup-mailer Re: DEFAULT-CASE
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 89 22:53:03 PST
Received: from franz.UUCP by ucbarpa.Berkeley.EDU (5.61/1.33)
id AA29249; Thu, 16 Mar 89 22:20:22 -0800
Received: from frisky by franz (3.2/3.14)
id AA22529; Thu, 16 Mar 89 21:39:21 PST
Received: by frisky (3.2/3.14)
id AA09727; Thu, 16 Mar 89 21:38:16 PST
From: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
Return-Path: <frisky!jkf>
Message-Id: <8903170538.AA09727@frisky>
To: David A. Moon <franz!ucbarpa!STONY-BROOK.SCRC.Symbolics.COM!Moon>
Cc: franz!sail.stanford.edu!CL-Cleanup
Subject: Re: DEFAULT-CASE
In-Reply-To: Your message of Thu, 16 Mar 89 18:15:00 EST.
<19890316231500.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 16 Mar 89 21:38:14 PST
I'm not trying to start a religious war. I'm not saying that
case-sensitive is better or worse than case-insensitive. I'm just
saying that there are large numbers of people who favor each position
and that Common Lisp should support both.
Regarding internal vrs external: The internal representation shows
through in a number of places. For example the functions symbol-name
and make-symbol let the user deal with the actual internal
representation of the names of symbols. The idea of having a
*print-case* value that inverts the case on output is interesting but
that would make things awkward: To make the symbol FooBar you
would have to (make-symbol "fOObAR"). Also examining the characters
of a print-name with aref would give confusing results.
>> I also claim that the choice of case in internal representation
>> is arbitrary and need not prejudice the external representation
>> at all.
For a case-insensitive Lisp I completely agree. For a case-sensitive
Lisp, as I've shown above, this just isn't true. Thus if the needs
of the case-sensitive Lisp are met, then the needs of both are met.
-john foderaro
[it might be interesting to explore the possiblity of explicitly
stating that the internal representation of print-names was undefined
with respect to case, and further providing two new functions: one
which took a string and converted it to the internal representation
just as the reader would do and the other which took a symbol-name
and converted it to a string just as the printer would do.
I suspect that this would lead to programs that worked on a few
Common Lisps but failed on others due to accidental reliance on the
actual case of the printnames. ]
∂16-Mar-89 2310 CL-Cleanup-mailer Re: Issue: IN-SYNTAX (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 23:10:33 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 23:05:56 PST
Date: 16 Mar 89 23:05 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: IN-SYNTAX (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Fri, 21 Oct 88 14:01 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890316-230556-6907@Xerox>
The discussion of this Issue quickly evolved into a discussion of the
default environment for LOAD. I don't see much in the way of the discussion
of the issue itself except "far too narrowly focused."
Under the circumstances -- and given that I'm not that thrilled by adding
Yet Another Puppy that We Aren't Sure We Need -- can we drop this?
∂17-Mar-89 0009 CL-Cleanup-mailer Cleanup Issue Status List
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 00:09:24 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 23:57:10 PST
Date: 16 Mar 89 23:56 PST
From: masinter.pa@Xerox.COM
cc: masinter.pa@Xerox.COM
to: cl-cleanup@sail.stanford.edu
Subject: Cleanup Issue Status List
Message-ID: <890316-235710-7002@Xerox>
I'm out of steam and only in the middle of the alphabet. I'll try to slug
through M-Z tomorrow. I'm travelling or unavailable most of next week, and
so this has to get done now.
! ready for vote
+ passed
!+: passed, but up for reconsideration
- withdrawn, failed, etc.
* pending, passed but need version as amended, etc.
+ ADJUST-ARRAY-DISPLACEMENT
Version 4, 23-Nov-87
Status: passed, 1988
+ ADJUST-ARRAY-FILL-POINTER
Version 1, 15-MAR-88
Status: passed, 1988
! ADJUST-ARRAY-NOT-ADJUSTABLE
Synopsis: ADJUST-ARRAY on array made with :ADJUSTABLE NIL: "an error"?
Version 4, 11-Jan-89, Released 12-Jan-89
Status: Accepted with amendments Jan 89 X3J13
Comments: amendment had wording problem.
Version 8, 11-Mar-89, Released 15-Mar-89
Status: ready for vote
- ALIST-NIL
Version 4, 1-Oct-88
Status: Withdrawn, recommend editorial
- APPEND-ATOM
Synopsis: atom case of APPEND (left out of APPEND-DOTTED)
Version 1, 6-Dec-88, Released 12-Jan-89
Status: withdrawn 18-Jan-89 because APPEND-DOTTED withdrawn
- APPEND-DOTTED
14-JAN-88, Version 5
Status: Passed Nov 88 X3J13, reconsidered & withdrawn Jan 89 X3J13
+ APPLYHOOK-ENVIRONMENT
Synopsis: remove (useless) env argument to applyhook
Version 2, 10-Jan-89, Released 10-Jan-89
Status: Passed Jan-89 X3J13
+ AREF-1D
14-NOV-87, Version 7
Status: Passed, 1988?
+ ARGUMENTS-UNDERSPECIFIED
Synopsis: Clarify various ranges missing from CLtL
Version 4, 21-Sep-88, Released 4 Dec 88
Status: Passed Jan 89 X3J13
+ AREF-1D
Version 7, 14-NOV-87
Status: Passed, 1988?
+ ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Synopsis: What do array element-type declarations mean?
Version 9, 31-Oct-88, Released 5 Dec 88
Status: Passed Jan 89 X3J13
+ ASSOC-RASSOC-IF-KEY
Version 4, 23-NOV-87
Status: Passed, 1988?
- BACKQUOTE-COMMA-ATSIGN-DOT
Synopsis: `(... ,@x) vs `(... . ,x). Same, different, is error?
Version 1, 22-Dec-88, DRAFT released
Comments: proposals INTERCHANGABLE and DIVERGENT comments not in writeup
Status: Withdrawn, since APPEND-DOTTED withdrawn. Default is IS ERROR
! BREAK-ON-WARNINGS-OBSOLETE
Synopsis: deprecate *BREAK-ON-WARNINGS* because of *BREAK-ON-SIGNALS*
Version 1, 07-Mar-89, Released 15-Mar-89
Comment: leaves out a case
Status: ready for vote
! CLOS-CONDITIONS
Version 4, 10-Mar-89
Comments: define metaclass of conditions?
Status: pending
+ CLOSE-CONSTRUCTED-STREAMS
Synopsis: What does it mean to CLOSE a constructed stream?
Version 2, 12-Jan-89, Released 12-Jan-89
Status: Proposal ARGUMENT-STREAM-ONLY passed Jan 89 X3J13
!+ CLOSED-STREAM-OPERATIONS
Synopsis: What operations are legal on closed streams?
Version 5, 5-Dec-88, released 5-Dec-88
Status: amended at meeting
Version 7, 14-Feb-89
Status: Passed, as amended, Jan 89 X3J13
Comment: amendment bad; reconsider version 5?
amend 5 to say that INPUT-STREAM-P and OUTPUT-STREAM-P
are undefined on closed streams?
! COERCE-INCOMPLETE
Synopsis: Extend COERCE
Version 3, 7-Mar-89, Released 14-Mar-89
Status: ready for voting
+ COLON-NUMBER
Synopsis: :123 is an error
22-OCT-87, Version 1
Status: Passed, 1988?
+ COMPILER-WARNING-STREAM
Version 6, 5-JUN-87
Status: Passed, 1988?
+ COMPLEX-ATAN-BRANCH-CUT
Synopsis: tweak upper branch cut in ATAN formula
Version 1, 13-Dec-88, Released 10-Jan-89
Status: Passed Jan 89 X3J13
! CONDITION-RESTARTS
Synopsis: can't know whether restart is associated with signalling
Version 1, 18-Jan-89, released 16-Mar-89
Comment: (proposed amendments)
Status: vote w/amendments or new version
+ CONTAGION-ON-NUMERICAL-COMPARISONS
Version 1, 14-Sep-88, Released 6 Oct 88
Status: passed, Jan 89 X3J13
! COPY-SYMBOL-COPY-PLIST
Version 1, 10-Jan-89, released 16-Mar-89
Status: ready for vote
! COPY-SYMBOL-PRINT-NAME
Version 2, 15-Mar-89, released 16-Mar-89
Status: ready for vote
+ DATA-TYPES-HIERARCHY-UNDERSPECIFIED
4-SEP-88 Version 2
Status: Passed, 1988?
+ DECLARATION-SCOPE
Version 4, 15-Nov-88, Released 9-Dec-88
Status: NO-HOISTING passed Jan 89 X3J13
+ DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Version 3, 13-Jan-89
Status: passed, Jan 89 X3J13
kc: amended?
+ DECLARE-FUNCTION-AMBIGUITY
Version 4, 5-Dec-88, Released 5-Dec-88
Status: passed, Jan 89 X3J13
+ DECLARE-TYPE-FREE
Version 10, 12-Jan-89
Status: proposal LEXICAL passed Jan 89 X3J13
+ DECLARE-MACROS
5-FEB-88, Version 3
Status: Passed, 1988?
- DECLARE-TYPE-USER-DEFINED
Synopsis: allow (declare ((signed-byte 8) x y z)) for all type specifiers?
Status: Withdrawn (never submitted)
+ DECODE-UNIVERSAL-TIME-DAYLIGHT
Version 2, 30-Sep-88, Released 6 Oct 88
Status: Passed, Jan 89 x3j13
- DEFINITION-DELETE
Synopsis: provide a way to get rid of structures, etc.
Status: not submitted
* DEFMACRO-LAMBDA-LIST
Version 1, 30-Jan-89
Status: *** NEED NEW VERSION ***
+ DEFPACKAGE
Version 7, 2-Nov-88, Released 5 Dec 88
Comment: clarify "at variance" in editorial work?
Status: Passed, Jan 89 X3J13
- DEFSTRUCT-ACCESS-FUNCTIONS-INLINE
Synopsis: defstruct accessors are proclaimed inline
Version 2, 7-Jan-89, released 10-Jan-89
Status: rejected, Jan 89 X3J13
+ DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
Version 3, 8-Jan-89, Released 11-Jan-89
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
Version 3, 7 Dec 88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-REDEFINITION
Synopsis: what happens if you redefine a DEFSTRUCT?
Version 3, 6-Feb-89
Status: Passed (as amended) Jan 89 X3J13
+ DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
Version 5, 12-Jan-89
Status: Passed, Jan 89 X3J13
+ DEFVAR-DOCUMENTATION
23-NOV-87, Version 2
Status: Passed, 1988?
+ DEFVAR-INIT-TIME
29-MAR-87, Version 2
Status: Passed, 1988?
+ DEFVAR-INITIALIZATION
Version 4 5-JUN-87
Status: Passed, 1988?
- DELETE-FILE-NONEXISTENT
Version 1, 5-Oct-88
Comments: should just signal different errors?
Status: withdrawn/tabled?
+ DESCRIBE-INTERACTIVE
Version 4, 15-Nov-88, Released 7-Dec-88
Synopsis: can DESCRIBE ask user a question?
Status: Proposal NO passed Jan 89 X3J13
! DESCRIBE-UNDERSPECIFIED
Version 1, 10-Mar-89, Released 16-Mar-89
Synopsis: making DESCRIBE generic was wrong; fix
status: ready for vote
!* DESTRUCTURING-BIND
Version 2, 25-Jan-89, Released 16-Mar-89
Synopsis: add DESTRUCTURING-BIND macro
Status: might need new version before vote
+ DISASSEMBLE-SIDE-EFFECT
Version 3 1/21/88
Status: Passed, 1988
+ DO-SYMBOLS-DUPLICATES
Version 3 23-NOV-87
Status: Passed, 1988?
+ DOTTED-MACRO-FORMS
Version 3, 15-Nov-88, Released 7-Dec-88
Status: passed, Jan 89 X3J13
+ DRIBBLE-TECHNIQUE
14-FEB-88, Version 2
Status: Passed, 1988?
! DYNAMIC-EXTENT
Version 3, 11-Jan-89, released 16-Mar-89
Comments: still some holes
Status: ready for vote?
- ELIMINATE-FORCED-CONSING
Synopsis: Add :RECYCLE or :MODIFY to some sequence fns,
Version 3, 31-Aug-88
Status: withdrawn
- ENVIRONMENT-ENQUIRY
Synopsis: "The environment inquiry functions (pp447-448) don't return a
value in consistent format across implementations. This makes
them virtually useless. I would like to constrain the values
enough so that implementors knew what to provide as return
values, and provide some examples of intended uses."
Status: no volunteer to submit
+ EQUAL-STRUCTURE
Version 6, 11-Jan-89, Released 12-Jan-89
Status: Passed with amendments
Version 7, 15-Mar-89
Status: Passed Jan 89 X3J13 as amended.
* EQUALP-GENERIC
Version 1, 28-Feb-89
Synopsis: make EQUALP generic function
Comments: Various problems being worked on
Status: ** NEED NEW VERSION ***
* ERROR-CHECKING-IN-NUMBERS-CHAPTER
Version 1, 6-Mar-89
Synopsis: define 'should signal', 'might signal' for number fns
Status: in progress, "endorse in principle"?
! ERROR-NOT-HANDLED
Version 1, 25-Sep-88, Released 6-Oct-88 and 14-Mar-89
Status: ready for vote
+ EVAL-OTHER
8-JUN-88, Version 2
Status: Passed, 1988?
! EXIT-EXTENT
Version 6, 8-Jan-89, distributed at Jan89 X3J13
Rereleased 16-Mar-89
Status: tabled Jan89; ready for vote
+ EXPT-RATIO
Version 3, 31-Oct-88, Released 7 Dec 88
Status: passed, Jan 89 X3J13
* EXPT-ZERO-ZERO
Synopsis: (EXPT 0.0 0.0) should be undefined
Version 1, 27-Feb-89
Status: need new version?
- FILE-LENGTH-PATHNAME
Synopsis: extend FILE-LENGTH to work on pathnames
Status: not submitted/ withdrawn
* FILE-WRITE-DATE-IF-NOT-EXISTS
Synopsis: What does FILE-WRITE-DATE do if no such file?
Version: no proposal
Status: => ERRORS-IN-FILE-SYSTEM-CHAPTER????
+ FIXNUM-NON-PORTABLE
Version 4, 7-Dec-88, Released 12-Dec-88
Status: Accepted with amendment
Version 5, 16-Mar-89, "as amended"
Comment: minor off-by-one in amendment
Status: voice approval for off-by-one?
+ FLET-DECLARATIONS
Version 2, 2 FEB 88
Status: Passed, 1988?
+ FLET-IMPLICIT-BLOCK
Version 6 5-JUN-87
Status: Passed, 1988?
- FOLLOW-SYNONYM-STREAM
Comment: lost in STREAM-ACCESS.
Status: Withdrawn?
+ FORMAT-ATSIGN-COLON
Version 4 5-JUN-87
Status: Passed, 1988?
+ FORMAT-COLON-UPARROW-SCOPE
Version 3, 5 FEB 88
Status: Passed, 1988?
+ FORMAT-COMMA-INTERVAL
Version 2, 15-JUN-87
Status: Passed, 1988?
+ FORMAT-E-EXPONENT-SIGN
Version 2, 2 Oct 88, Released 6 Oct 88
Status: Passed, Jan 89 X3J13
+ FORMAT-OP-C
11-JUN-87, Version 5
Status: Passed, 1988?
- FORMAT-NEGATIVE-PARAMETERS
Synopsis: What does FORMAT do when it gets negative numbers for count?
Version: No proposal
Comment: KMP will incorporate in the list-of-signals part of the signal
proposal?
Status: not submitted
* FORMAT-PLURALS
Synopsis: remove ~P, add ~:@[singular~;plural~]
Status: no proposal
+ FORMAT-PRETTY-PRINT
Version 7, 15 Dec 88, Released 7 Dec 88
Comments: passed, Jan 89 X3j13
- FORMAT-ROUNDING
Synopsis: specify that ~F rounds up
Version 1, 5-Oct-88
Status: withdrawn
* FUNCTION-ARGUMENT-LIST
Synopsis: want way to get argument list
Status: not submitted
+ FUNCTION-CALL-EVALUATION-ORDER
Version 1, 22-MAR-88
Status: Passed, 1988
! FUNCTION-COERCE-TIME
Synopsis: When does SYMBOL-FUNCTION happen in MAPCAR?
Version 2, 16-sep-88, Released 8-Oct-88
Re-released: 16-Mar-89
Status: vote?
+ FUNCTION-COMPOSITION
Synopsis: Add new functions
Version 5, 10-Feb-89
Status: Passed (as amended) Jan 89 X3J13?
Status: maybe this was passed as amendment to TEST-NOT-IF-NOT instead
but in either case, we have the content.
+ FUNCTION-DEFINITION
Version 3, 10-Feb-89
Status: Passed (as amended) Jan 89 X3J13
+ FUNCTION-TYPE
4-SEP-88, Version 12
Status: Passed, 1988
+ FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
Synopsis: Change semantics of argument types in function declarations
Version 3, 7-Dec-88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13
+ FUNCTION-TYPE-KEY-NAME
Version 3, 13-FEB-88
Status: Passed, 1988
+ FUNCTION-TYPE-REST-LIST-ELEMENT
Version 5, 14-Nov-88, Released 8-Dec-88
Status: Passed, Jan 89 X3J13
- GCD-NO-ARGUMENTS
Synopsis: make (GCD) undefined
Status: not submitted
*! GENSYM-NAME-STICKINESS
Version 1, 14-Feb-89, Released 14-Mar-89
Synopsis: no side effects if optional arg supplied
Status: need new version
- GET-MACRO-CHARACTER-DISPATCHING
Synopsis: What does GET-MACRO-CHARACTER return for dispatching macros?
Status: not submitted
+ GET-MACRO-CHARACTER-READTABLE
Version 3, 11-Feb-89
Status: Passed (as amended) Jan 89 X3J13
+ GET-SETF-METHOD-ENVIRONMENT
Version 5 13-JUL-87
Status: Passed, 1988?
! HASH-TABLE-ACCESS
Synopsis: Add new accessors for hash-table properties
Version 1, 13-Sep-88 released 8-Oct-88
Version 2, 13 Oct 88, released 16-Mar-89
status: vote
- HASH-TABLE-GC
Synopsis: allow hash tables with GCable keys
Status: no proposal
+ HASH-TABLE-PACKAGE-GENERATORS
Version 7, 8-Dec-88, Released 9-Dec-88
Comments: The test-package-iterator example has the values
from the generator in the wrong order.
Status: passed, Jan 89 X3J13
* HASH-TABLE-PRINTED-REPRESENTATION
Version 2, 8-Jun-88
Comments: Use #S(ARRAY ...), #S(HASH-TABLE...), #S(PATHNAME...)?
Status: need new proposal
- HASH-TABLE-STABILITY
Version 1, 11-Nov-88, Released 12 Dec 88
Comments: superceded HASH-TABLE-KEY-MODIFICATION
Status: Rejected Jan 89 X3J13
+ HASH-TABLE-TESTS
Version 2, 8-Dec-88, Released 8 Dec 8 8
Status: passed Jan 89 X3J13
+ IEEE-ATAN-BRANCH-CUT
Version 2, 11-Jan-89, Released 11-Jan-89
Status: passed, Jan 89 X3J13
* IGNORE-VARIABLE
Synopsis: default (IGNORE IGNORE)
Version 1, 6-Feb-89
+ IMPORT-SETF-SYMBOL-PACKAGE
Version 5 ??-MAY-87
Status: Passed, 1988?
! IN-PACKAGE-FUNCTIONALITY
Version 4, 12-Dec-88, Released 12-Dec-88
Status: tabled
Version 8, 15-Mar-89, Released 15-Mar-89
Status: ready for vote
- IN-SYNTAX
Synopsis: like IN-PACKAGE but for readtables
Version 1, 21-Oct-88
Comments: important issue: default environment for LOAD
Status: can we withdraw?
- INPUT-STREAM-P-CLOSED
Synopsis: What do INPUT-STREAM-P and OUTPUT-STREAM-P do on closed streams?
Status: not submitted
- INPUT-STREAM-P-EXAMPLE
Synopsis: (input-stream-p (make-broadcast-stream)) is NIL
Version 1, 26-Oct-88
Status: bug report, needs no clarification?
+ KEYWORD-ARGUMENT-NAME-PACKAGE
8-NOV-87, Version 8
Status: Passed, 1988?
- LAMBDA-FORM
Version 4, 22-Nov-88, Released 8-Dec-88
Status: rejected, Jan 89 X3J13
+ LAST-N
12-MAR-88, Version 2
Status: Passed, 1988?
+ LCM-NO-ARGUMENTS
Version 1, 17 Oct 88, Released 8 Dec 88
Status: passed, Jan 89 X3J13
- LEAST-POSITIVE-SINGLE-FLOAT-NORMALIZATION
Synopsis: should LEAST-POSITIVE- and MOST-POSITIVE-XXX-FLOAT
numbers include denormalized ones in those implementations
that admit them?
Status: Not submitted
! LISP-PACKAGE-NAME
Synopsis: change LISP to COMMON-LISP to avoid CLtL confusion
Version 1, 22 Dec 88, Released 11-Jan-89
Status: tabled; version 1 still ready for vote
! LISP-SYMBOL-REDEFINITION
Version 5, 22-Nov-88, Released 8 Dec 88
Comments: Don't like (DEFVAR CAR ...) example
14: Like simpler "Redefining any documented
definition on a symbol in the LISP package -- such as variables,
functions, constants, properties and property-lists, etc -- is
undefined, except for the explicitly allowed cases (e.g. dynamic
binding of variables)."
Status: tabled; version 5 still ready for vote
- LIST-TYPE-SPECIFIER
Synopsis: add a type specifier (LIST NUMBER)
Version 1, 28 Jun 88
Status: withdrawn
! LOAD-OBJECTS
Synopsis: Provide a way to allow defstruct/defclass objects in compiled
files
Version 3, 9-Mar-89, released 16-Mar-89
Status: ready for vote?
! LOAD-TRUENAME
Synopsis: Make default pathname for LOAD inside LOAD same?
Version 1, 13-Mar-89, Released 16-Mar-89
Status: ready for vote
! LOOP-AND-DISCREPANCY
Version 1, 15-Mar-89, released 16-Mar-89
status: ready for vote
+ MACRO-FUNCTION-ENVIRONMENT
Version 2, 8-JUN-88
Status: Passed, 1988
* MACRO-SPECIAL-FORMS
Synopsis: macros expanding to implementation-dependent special forms
doesn't work
Status: not yet submitted
- MAKE-CONCATENATED-STREAM-EXAMPLE
Synopsis: (read (make-concatenated-stream (make-string-input-stream "1")
(make-string-input-stream "2"))) => 12?
Version 1, 26-Oct-88
Status: withdrawn, no issue (bug report to one implementation)
+ MAKE-PACKAGE-USE-DEFAULT
Version 2, 8 Oct 88, Released 12-Dec-88
Version 3, 16-Mar-89
Status: Passed, Jan 89 X3J13 as amended
! MAKE-STRING-FILL-POINTER
Synopsis: extend MAKE-STRING to take a fill-pointer?
Version 1, 20-Oct-88, released 16-Mar-89
Status: vote?
+ MAPPING-DESTRUCTIVE-INTERACTION
Version 2, 09-Jun-88, Released 8 Oct 88
Synopsis: [don't] define interaction of DELETE on MAPCAR'd list.
Status: passed, Jan 89 X3J13
* NTH-VALUE
Version 4, 8-Dec-88, Released 8 Dec 88
Comments: Accepted (9 to 7), with amendment to clarify what happens if n is
out of range
Status: need new version as amended
- OUTPUT-STREAM-P-EXAMPLE
Synopsis: Clarify (output-stream-p (make-concatenated-stream)) is NIL?
Version 1, 26-Oct-88
Comment: already clear; just bug report for one implementation
* PACKAGE-CLUTTER
Version 6, 12-Dec-88, Released 12-Dec-88
Comments: Accepted, with amendment that the forbidden property indicators
are
external symbols in all packages defined by this standard plus all
symbols accessible in the USER package or in packages defined by
the user.
Status: need writeup as amended
+ PACKAGE-DELETION
Version 5, 21 nov 88, Released 8 Dec 88
Comments: Minor glitches? Remove the description of "correctable" error to
be signalled and
handled.
Status: passed, Jan 89 X3J13
* PACKAGE-FUNCTION-CONSISTENCY
Synopsis: allow strings for package arg everywhere uniformly
Version 2, 12-Jan-89, Released 12-Jan-89
Comment: Accepted MORE-PERMISSIVE (v2), as amended
----- Moon 21-Jan-89 (Version 2) -----
MORE-PERMISSIVE is like PERMISSIVE except that the four
functions
identified by CLtL as "package structure accessors" that don't
allow
names are changed to allow names.
Amendments made at the meeting added DELETE-PACKAGE and
DEFPACKAGE
to the list of functions and removed the paragraph beginning
with the words "If IN-PACKAGE...".
Status: need new version as amended
* PATHNAME-CANONICAL-TYPE
Synopsis: allow canonical :SOURCE-LISP to MAKE-PATHNAME;
require PATHNAME-TYPE to return same?
Version 1, 07-Jul-88
Comments: only add the :TYPE :SOURCE-LISP, not PATHNAME-CANONICAL-TYPE?
Status: => "pathname" committee?
* PATHNAME-COMPONENT-CASE
Synopsis: allow ALL UPPER CASE to mean "use the 'right' case
Comments: lots of heat?
Status: => "pathname" committee
* PATHNAME-EXTENSIONS
Synopsis: allow a way of telling whether a pathname is a pattern, a "funny"
file
Comments: necessary in standard?
Status: => "pathname" committee
* PATHNAME-LOGICAL
Synopsis: add logical pathnames (pathnames for an imaginary portable
file system, which get translated by site-dependent translations into
physical pathnames on an actual file system)
Status: no proposal yet
* PATHNAME-PRINT-READ
Synopsis: Print pathnames like #P"asdf"?
Version 1, 21-Oct-88
Comments: Numerous, pro, con. Print like #S(pathname ...)?
Status: need new version
+ PATHNAME-STREAM
Version 6 14-NOV-87
Status: Passed, 1988?
+ PATHNAME-SYMBOL
Version 5 5-FEB-88
Status: Passed, 1988?
* PATHNAME-SUBDIRECTORY-LIST
Synopsis: How to deal with subdirectory structures in pathname functions
Version 3, 29-Dec-88
Comments: typos and proposed simplifications
Status: need new version
* PATHNAME-SYNTAX-ERROR-TIME
Synopsis: when are errors in pathnames detected?
Version 1, 7-Jul-88
Comments: various
Status: need new version
- PATHNAME-TYPE-UNSPECIFIC
Version 1 27-Jun-88, Released 7 Oct 88
Comments: may be subsumed
Status: withdrawn; superceded by PATHNAME-UNSPECIFIC-COMPONENT
* PATHNAME-UNSPECIFIC-COMPONENT
Version 1, 29-Dec-88, Released 12-Jan-89
Synopsis: More extensions to :UNSPECIFIC
Comment: Accepted (14 to 4), with amendments to allow any field to be
:UNSPECIFIC including host and name, and to say that "To use
:UNSPECIFIC in an operating system for which it does not make
sense, the results are undefined."
----- Moon 21-Jan-89 -----
RWK pointed out that :UNSPECIFIC has two meanings: the component
is omitted in this particular pathname (type in Unix) or the
component is not meaningful for this system (version in Unix).
Cross-host defaulting needs to treat those differently, so
:UNSPECIFIC can't get into a field where it is not allowed.
In the end RWK suggested people should vote for the proposal
anyway, as it was a net improvement.
Status: needs new version as amended
* PATHNAME-WILD
Version 2, 6-Oct-88
Synopsis: Portable way to ask about "wildcard" pathnames?
Comments: consistent with PATHNAME-COMPONENT-CASE?
Status: => "pathname" committee
+ PEEK-CHAR-READ-CHAR-ECHO
Version 3, 8-Oct-88, Released 8 Oct 88
Synopsis: PEEK-CHAR, READ-CHAR on streams made by MAKE-ECHO-STREAM
Status: Passed, Jan 89 X3J13
+ PRINC-CHARACTER
29-APR-87, Version 2
Status: Passed, 1988?
* PRINT-CIRCLE-SHARED
Synopsis: does *PRINT-CIRCLE* cause shared structure to print with #=?
Status: Not submitted
* PRINT-CIRCLE-STRUCTURE
Version 3, 20 Sep 88, Released 8 Oct 88
Comments: Accepted, with amendment to apply to methods on PRINT-OBJECT in
addition to :PRINT-FUNCTION options
Status: need new version as amended
* PROCLAIM-LEXICAL
Version 9, 8-Dec-88, Released 12-Dec-88
Synopsis: add LEXICAL proclaimation
Comments: lengthy mail; amendments at Jan meeting
Status: tabled, *** NEED NEW VERSION ***
+ PUSH-EVALUATION-ORDER
Version 5, 25-NOV-87
Status: Passed, 1988?
+ RANGE-OF-COUNT-KEYWORD
Version 3, 9-Oct-88, Released 14-Oct-88
Status: passed, Jan 89 X3J13
+ RANGE-OF-START-AND-END-PARAMETERS
Version 1, 14-Sep-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
* READ-CASE-SENSITIVITY
Synopsis: Allow readtables to be case sensitive
Status: ready for release???
* READ-DELIMITED-LIST-EOF
Synopsis: eof in read deliminted list signals an error
Status: awaiting submission
! REAL-NUMBER-TYPE
Synopsis: add REAL = (OR RATIONAL FLOAT) & range
Version 3, 13-Jan-89, released 16-Mar-89
Status: vote?
+ REDUCE-ARGUMENT-EXTRACTION
Version 3 13-FEB-88
Status: Passed, 1988?
* REMF-DESTRUCTION-UNSPECIFIED
Synopsis: Specification of side-effect behavior in CL
Version 2, 29-Oct-87, Released 8-Oct-88
Version 4, 29-Nov-88, Released 12-Jan-89
Status: There was a straw vote in favor of this, then BarMar was appointed
to make some amendments and put it on the letter ballot. I
think the
amendments are to tighten up NCONC and remove NBUTLAST, NSUBSTx,
and NSUBSTITUTEx.
- REMF-MULTIPLE
Synopsis: What does REMF do if it sees more than one INDICATOR?
Version 2, 12-Jan-89, Released 12-Jan-89
Status: withdrawn ("only applies in 'cannot happen' situation")
+ REQUIRE-PATHNAME-DEFAULTS
Version 6, 9 Dec 88, Released 09 Dec 88
Status: passed, Jan 89 X3j13
+ REST-LIST-ALLOCATION
Version 3, 12-Dec-88, Released 12-Dec-88
Status: proposal MAY-SHARE passed, Jan 89 X3J13
- REST-LIST-EXTENT
Synopsis: allow way to declare dynamic extent &REST
Comment: superseded by DYNAMIC-EXTENT
Status: withdrawn
+ RETURN-VALUES-UNSPECIFIED
Version 6, 9 Dec 88, Released 9-Dec-88
Status: passed, Jan 89 X3J13
+ ROOM-DEFAULT-ARGUMENT
Version 1, 12-Sep-88, Released 8 Oct 88
Status: passed, Jan 89 X3J13
- SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
Version 6, 06-Oct-88, Released 11-Jan-89
Comments: New version scales down previously rejected version
Status: Version 6 rejected Jan 89 X3J13
! SETF-FUNCTION-VS-MACRO, SETF-PLACES, FUNCTION-NAME
Comment: either renaming or separate proposals, depending
on your point of view
SETF-FUNCTION-VS-MACRO
Version 3, 4-Nov-87, Released Nov 87
SETF-PLACES
Version 1, 11-Nov-88, Released 9-Dec-88
FUNCTION-NAME
Version 1, 27-Jan-89, Released 16-Mar-89
Status: ready for vote
* SETF-MULTIPLE-STORE-VARIABLES
Synopsis: Allow multiple "places" in SETF stores
Version 1, 5-Dec-88
Status: awaiting new version
+ SETF-SUB-METHODS
Version 5, 12-Feb-88, Released 8 Oct 88
Synopsis: careful definition of order inside (SETF (GETF ...) ...)
Status: passed, Jan 89 X3J13
+ SHADOW-ALREADY-PRESENT
Version 4 10-NOV-87
Status: Passed, 1988?
+ SHARPSIGN-PLUS-MINUS-PACKAGE
Version 3 14-NOV-87
Status: Passed, 1988?
* SINGLE-FLOAT-NON-PORTABLE
Synopsis: remove SINGLE-FLOAT, DOUBLE-FLOAT a la FIXNUM?
Status: Not submitted
+ SPECIAL-TYPE-SHADOWING
Synopsis: intersection of types when proclaimed special has local type
declaration
Version 1, 4-Nov-88, released 11-Jan-89
Status: passed, Jan 89 X3J13
SPECIAL-VARIABLE-TEST
Synopsis: Add SPECIAL-VARIABLE-P?
Version 2, 31-May-88
Status: "On hold pending SYNTACTIC-ENVIRONMENT-ACCESS"
+ STANDARD-INPUT-INITIAL-BINDING
Version 8, 8 Jul 88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
* STANDARD-VALUE
Synopsis: user can say binding is "temporary"
Version 1, 21-Oct-88
Comments: not worth trying to standardize now?
Status: ready for release?
* STEP-ENVIRONMENT
Version 3, 20-Jun-88, Released 7 Oct 88
Comments: Passed, Jan 89.
Verbally this was explained to mean that the body of the STEP would
not be stepped when compiled, but if it just happened to call an
interpreted function, that function would get stepped. Also the
word "evaluation" in that sentence was amended to "computation."
Status: need new version as amended
+ STREAM-ACCESS
Version 2, 30-Nov-88, Released 9 Dec 88
Status: ADD-TYPES-ACCESSORS passed, Jan 89 X3J13
* STREAM-CAPABILITIES
Version 1, 7/5/88
Synopsis: SAME-SOURCE-P, SAME-DESTINATION-P, etc
Status: awaiting new version, from "pathname/file" committee?
* STREAM-DEFINITION-BY-USER
Synopsis: Want user-definable stream types.
Status: not submitted
* STREAM-ELEMENT-TYPE-EXAMPLES
Version 1, 26-Oct-88
Synopsis: clarify STREAM-ELEMENT-TYPE may return different values?
Status: editorial? Need new proposal?
- STREAM-INFO
Version 6, 30-Nov-88, Released 9 dec 88
Status: Rejected, Jan 89 X3J13
+ SUBSEQ-OUT-OF-BOUNDS
29-MAR-88 Version 2
Status: Passed, 1988?
* SUBTYPEP-ENVIRONMENT
SUBTYPEP-EMPTY-NIL
Version 1
Status: => editorial, no cleanup needed
+ SUBTYPEP-TOO-VAGUE
Version 4, 7-Oct-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
* SYMBOL-MACROFLET
Version 1, 30 Sep 88
Synopsis: Add SYMBOL-MACROFLET gives lexical function expansion
Status: need new version
+ SYMBOL-MACROLET-DECLARE
Version 2, 9-Dec-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13
!+ SYMBOL-MACROLET-SEMANTICS
Version 5, 30-Nov-88, Released 9 Dec 88
Status: Passed, Jan 89 X3J13
Version 6, 14-Mar-89, released 16-Mar-89
Status: ready for vote
- TAGBODY-CONTENTS
Version 5, 9-Dec-88, Released 9 Dec 88
Comments: "good that this failed, but we still need a clarification"
Status: Failed, Jan 89 X3J13
+ TAILP-NIL
Version 5, 9-Dec-88, Released 12-Dec-88
Synopsis: Operation of TAILP given NIL
Status: passed, Jan 89 X3J13
* TEST-NOT-IF-NOT
Version 3, 1 Dec 88, Released 9 dec
Comments: passed, Jan 89 X3J13 FLUSH-ALL, amended to deprecate instead of
removing
Status: Need new version as amended.
* THE-AMBIGUITY
Version 2, 11-Jan-89, Released 11-Jan-89
Comments: typo, sense wrong
Status: tabled
! TIME-ZONE-NON-INTEGER
Version 1, 13-Mar-89, Released 16-Mar-89
Status: ready for vote
- TRACE-ERROR
Synopsis: TRACE should signal errors if it doesn't understand
Version 1, 20-Jun-88
Comments: is this a cleanup?
Status: withdrawn
- TRACE-FUNCTION-ONLY
Synopsis: extend TRACE to handle other specs
Comment: we don't like it
Status: withdrawn
* TRUENAME-SYNTAX-ONLY
Version 1, 12-Sep-88
Synopsis: when does TRUENAME perform checking?
Comments: other options? leave more vague? Other questions?
Status: need new version => "pathname" committee
+* TYPE-OF-UNDERCONSTRAINED
Version 3, 12-Dec-88, Released 12 Dec 88
Comments: Accepted, with amendments
Version 5, 16-Mar-89
Status: Ready for release?
Status: need new version as amended
* TYPE-SPECIFIER-PREDICATE
Synopsis: "Add a new function TYPE-SPECIFIER-P that is true of valid type
specifiers and false of all other Lisp objects. Note that the use of
DEFSTRUCT and DEFTYPE can change the behavior of TYPE-SPECIFIER-P over
time."
Comments: considerable discussion on common lisp mailing list.
Status: Not yet submitted
* UNDEFINED-VARIABLES-AND-FUNCTIONS
Synopsis: What happens on an undefined function call, unbound variable ref?
Version 1, 29-Nov-88, Released 11-Jan-89
Comments: Lumping SLOT-UNBOUND in with unbound special variables was a
mistake,
as SLOT-UNBOUND is an extension mechanism, not only a safety
checking
mechanism. Also there were some wording problems. Gabriel and
Gregor
are to submit a revised proposal.
Status: pending
+ UNREAD-CHAR-AFTER-PEEK-CHAR
Version 2, 2-Dec-88, Released 12-Dec-88
Status: passed, Jan 89 X3J13
+ VARIABLE-LIST-ASYMMETRY
Version 3, 08-Oct-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13
+ WITH-OUTPUT-TO-STRING-APPEND-STYLE
Version 5, 7-JUN-88
Status: Passed, 1988?
----- End Forwarded Messages -----
----- End Forwarded Messages -----
----- End Forwarded Messages -----
----- End Forwarded Messages -----
----- End Forwarded Messages -----
----- End Forwarded Messages -----
----- End Forwarded Messages -----
∂17-Mar-89 0823 CL-Cleanup-mailer Re: DEFAULT-CASE
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 17 Mar 89 08:23:49 PST
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 17 Mar 89 11:19:44 EST
To: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
cc: cl-cleanup@sail.stanford.edu
Subject: Re: DEFAULT-CASE
In-reply-to: Your message of Thu, 16 Mar 89 21:38:14 -0800.
<8903170538.AA09727@frisky>
Date: Fri, 17 Mar 89 11:19:37 EST
From: Scott.Fahlman@B.GP.CS.CMU.EDU
I'm not trying to start a religious war. I'm not saying that
case-sensitive is better or worse than case-insensitive. I'm just
saying that there are large numbers of people who favor each position
and that Common Lisp should support both.
I'm trying to stay out of most cleanup discussions these days, but feel
compelled to say something about this one, especially since John indicated
that he was reading silence as non-disagreement.
The argument here is that we should make it easy for those people who
prefer case-sensitivity to write their code that way and for those who like
case-insensitivity (with symbols being bashed into some canonical case) to
write their code that way. I think that this is a recipe for consfusion
and major portability problems. As soon as there is code around that
assumes case sensitivity, anyone who wants to use that code in conjuction
with code of his own has to go along with case sensitivity. Attempts to
mix the two styles will break. It would be like the old days when half the
Lisp world used octal and the other half used decimal. So if this measure
is adopted, it won't be a matter of "freedom of choice". We'll either have
two incompatible software words within Common Lisp, or it will drag us all
through a major incompatible change we don't want.
I think we have to choose one style or the other for code if portability is
to be maintained. For better or for worse, we made that choice in favor of
a case-bashing convention. I don't think I'd favor the same choice again
if compatibility with the past were not an issue, but I don't think we can
make such a sweeping incompatible change now. And we can't straddle the
fence.
I've got no problem with a proposal that would allow the Common Lisp reader
to go into some non-case-smashing mode. This would be useful when the
reader is reading code for some embedded language with different case
rules, building up a dtabase, or doing other tasks. But we should make it
clear that when reading Common Lisp code, the case-bashing convention still
holds.
-- Scott
∂17-Mar-89 0838 CL-Cleanup-mailer Issue: FUNCTION-COERCE-TIME (Version 2)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 08:38:32 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Fri, 17 Mar 89 11:34:48 EST
Date: Fri, 17 Mar 89 11:35 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: FUNCTION-COERCE-TIME (Version 2)
To: cl-cleanup@sail.stanford.edu
Cc: Masinter.pa@xerox.com
In-Reply-To: <890316-221804-6820@Xerox>
Message-Id: <19890317163539.1.BARMAR@OCCAM.THINK.COM>
I favor LAZY, and then HYBRID. I don't think performance is a
significant issue, as programmers can always get ambitious semantics by
specifying #'symbol or (symbol-function 'symbol) explicitly instead of
'symbol. I believe that anyone who specifies the symbol instead of the
function is doing it precisely for its lazy semantics.
I like LAZY best because it makes all functions that take functional
arguments consistent.
barmar
∂17-Mar-89 0847 CL-Cleanup-mailer Re: DEFAULT-CASE
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 08:47:29 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 559518; Fri 17-Mar-89 11:44:50 EST
Date: Fri, 17 Mar 89 11:44 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: DEFAULT-CASE
To: John Foderaro <franz!frisky!jkf@ucbarpa.Berkeley.EDU>
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <8903170538.AA09727@frisky>
Message-ID: <19890317164453.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 16 Mar 89 21:38:14 PST
From: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
I'm not trying to start a religious war. I'm not saying that
case-sensitive is better or worse than case-insensitive. I'm just
saying that there are large numbers of people who favor each position
and that Common Lisp should support both.
Agreed. I'm trying to help you not start a religious war.
Regarding internal vrs external: The internal representation shows
through in a number of places. For example the functions symbol-name
and make-symbol let the user deal with the actual internal
representation of the names of symbols. The idea of having a
*print-case* value that inverts the case on output is interesting but
that would make things awkward: To make the symbol FooBar you
would have to (make-symbol "fOObAR"). Also examining the characters
of a print-name with aref would give confusing results.
The internal representation is accessible to programs, but I don't think
it's particularly important. You seem to disagree. It might be that we
have different experience with how often these primitives are used in
portable programs. I don't think they are used enough that having an
internal representation in the opposite case from the external one would
cause bugs, but I do think they are used often enough that an incompatible
change would cause bugs in the medium term.
>> I also claim that the choice of case in internal representation
>> is arbitrary and need not prejudice the external representation
>> at all.
For a case-insensitive Lisp I completely agree. For a case-sensitive
Lisp, as I've shown above, this just isn't true. Thus if the needs
of the case-sensitive Lisp are met, then the needs of both are met.
True, but if the discussion gets side-tracked by flaming controversy over
the relatively unimportant issue of internal representation, I suspect
that the only outcome will be that everyone will give up on reaching a
concensus and we will be stuck with the status quo. On the other hand,
if you compromise and keep the internal representation compatible, I
predict that you can very easily get what you really want, at the cost
of having a language 0.01% more inelegant than it would otherwise be.
∂17-Mar-89 0859 CL-Cleanup-mailer Re: issue HASH-TABLE-PRINTED-REPRESENTATION, v.2
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 08:59:00 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 17 MAR 89 08:53:42 PST
Date: 17 Mar 89 08:52 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue HASH-TABLE-PRINTED-REPRESENTATION, v.2
In-reply-to: Dave.Touretzky@B.GP.CS.CMU.EDU's message of Fri, 09 Dec 88
04:43:36 EST
To: Dave.Touretzky@cs.cmu.edu, cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <890317-085342-8373@Xerox>
If someone brings a new draft to the March 89 X3J13, we can
put it on the agenda and discuss it.
- - - - - - - -
Return-Path: <CL-Cleanup-mailer@SAIL.Stanford.EDU>
Redistributed: xerox-cl-cleanup↑.pa
Received: from SAIL.Stanford.EDU ([36.86.0.194]) by Xerox.COM ; 08 DEC 88 12:24:47 PST
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Dec 88 12:21:22 PST
Received: from Semillon.ms by ArpaGateway.ms ; 08 DEC 88 12:00:50 PST
Date: 8 Dec 88 12:00 PST
From: masinter.pa
Subject: Re: issue HASH-TABLE-PRINTED-REPRESENTATION
In-reply-to: masinter.pa's message of 14 Nov 88 15:50 PST
To: cl-cleanup@sail.stanford.edu, Dave.Touretzky@B.GP.CS.CMU.EDU
Message-ID: <881208-120050-4123@Xerox>
I like Kent's idea
" I (KMP) made a note to myself that since #S(ARRAY ...) and
#S(HASH-TABLE ...) couldn't possibly be meaningful, one might define
#S to be the generalized constructor for things other than structures.
So #S(ARRAY ...) could be used to print arrays with attributes that
would otherwise be lost. eg, #S(ARRAY :CONTENTS ... :FILL-POINTER ...).
Similarly, #S(HASH-TABLE :CONTENTS ... :SIZE ...) for the cases where
hairy options wanted to be shown. #A and the simpler #H notation could
then be used unless some option variable were set that said to really
print the full-blown info."
However, this issue is not going anywhere -- there were certainly
more No's than Yes's to proceed with the latest draft.
Return-Path: <Dave.Touretzky@dst.boltz.cs.cmu.edu>
Received: from DST.BOLTZ.CS.CMU.EDU ([128.2.220.61]) by Xerox.COM ; 09 DEC 88 01:44:26 PST
Received: from DST.BOLTZ.CS.CMU.EDU by DST.BOLTZ.CS.CMU.EDU; 9 Dec 88 04:43:48 EST
To: masinter.pa
cc: cl-cleanup@sail.stanford.edu
Reply-To: Dave.Touretzky@cs.cmu.edu
Subject: Re: issue HASH-TABLE-PRINTED-REPRESENTATION
In-reply-to: Your message of 08 Dec 88 12:00:00 -0800.
<881208-120050-4123@Xerox>
Date: Fri, 09 Dec 88 04:43:36 EST
Message-ID: <3932.597663816@DST.BOLTZ.CS.CMU.EDU>
From: Dave.Touretzky@B.GP.CS.CMU.EDU
I like KMP's idea too. In fact, if KMP's extension to #S were passed, I
would be happy to shelve the #H proposal. I want hash tables to have a
READable printed representation, but I don't want to squander the remaining
# macro dispatch characters on obscure bits of syntax. People will want to
type in arrrays as constants (with #A) much more frequently than hash
tables, so #A is needed but #H is diposable.
-- Dave
∂17-Mar-89 0910 CL-Cleanup-mailer Re: Issue: COERCE-INCOMPLETE (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 09:09:51 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 559547; Fri 17-Mar-89 12:05:36 EST
Date: Fri, 17 Mar 89 12:05 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: COERCE-INCOMPLETE (Version 3)
To: sandra%defun@cs.utah.edu
cc: barmar@Think.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM,
masinter.pa@xerox.com, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8903171654.AA06800@defun.utah.edu>
Message-ID: <890317120519.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
[X3J13 removed as overkill for this level of discussion; CL-Cleanup added]
Date: Fri, 17 Mar 89 09:54:35 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
... BarMar is right. I have a hardcopy of the FUNCTION-TYPE writeup that
was mailed on 4 Sep 88, with a note from Larry indicating that it's
the final version as passed at the June meeting. It includes
COERCE'ing of lambda expressions to functions as item 6b. ...
Yeah, it's the same in my copy. Sorry about that. I just stopped reading
too soon. Thanks for catching this.
I don't think this is a valid argument for not getting rid of COERCE,
since it is easy to coerce a lambda expression to a function using
(EVAL `(FUNCTION ,x)).
I mostly agree, but I admit that most other coercion operators don't force
you to cons unnecessary intermediate structure in order to do the coercion.
Having something like the original SCHEME's ENCLOSE operator wouldn't bother
me at all. Too bad we didn't pick the name DISCLOSE for what ended up being
FUNCTION-LAMBDA-EXPRESSION. I guess the right name for the ENCLOSE function
at this point is LAMBDA-EXPRESSION-FUNCTION.
∂17-Mar-89 1032 CL-Cleanup-mailer DYNAMIC-EXTENT
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Mar 89 10:32:06 PST
Received: from ISABEL-PERON.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 182328; Fri 17-Mar-89 13:26:45 EST
Date: Fri, 17 Mar 89 13:29 EST
From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
Subject: DYNAMIC-EXTENT
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <890316-120057-5042@Xerox>
Message-ID: <19890317182930.6.MLY@ISABEL-PERON.AI.MIT.EDU>
I don't see any way in the proposal to declare that a closure itself, rather than
its arguments, has dynamic extent. My greatest single use for dynamic-extent
declarations is to ensure stack-consing of closures.
Symbolics have a declaration SYS:DOWNWARD-FUNCTION for this case.
Perhaps CL could use DYNAMIC-EXTENT-FUNCTION
(flet ((test (a b)
(declare (dynamic-extent-function))
...))
(foo #'test))
(foo (lambda (a b)
(declare (dynamic-extent-function))
...))
Another feature which I find sorely needed (and which nobody seems
to support) is a way to declare that the result of a form
has dynamic extent. For example,
(defmacro with-frob (thunk &body body)
`(let ((*frob-stack* (cons (the dynamic-extent-object ,thunk) *frob-stack*)))
(declare (dynamic-extent *frob-stack*))
,@body))
The idea is to avoid making all users of the with-frob macro
put in explicit dynamic-extent-function declarations.
∂17-Mar-89 1044 CL-Cleanup-mailer Re: DEFAULT-CASE
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 17 Mar 89 10:43:34 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa08901; 17 Mar 89 18:19 GMT
Date: Fri, 17 Mar 89 18:18:11 GMT
Message-Id: <4955.8903171818@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: DEFAULT-CASE
To: "David A. Moon" <Moon@scrc-stony-brook.arpa>,
John Foderaro <@NSS.Cs.Ucl.AC.UK,@aiai.edinburgh.ac.uk,@ucbarpa.berkeley.edu,@franz:jkf@frisky>
In-Reply-To: David A. Moon's message of Thu, 16 Mar 89 18:15 EST
Cc: CL-Cleanup@sail.stanford.edu
> Proposal (DEFAULT-CASE:LOWER)
>
> The case of all characters in the names of standard
> functions, symbols, and packages is lower.
>
> You're proposing a huge incompatible change that is bound to
> get you into a religious war that can't do anyone any good.
> I claim that this proposal addresses the internal representation
> of programs but all you care about is the external representation.
> I also claim that the choice of case in internal representation
> is arbitrary and need not prejudice the external representation
> at all.
That is almost true, but not compeletly. What about FIND-SYMBOL and
the like? So the programmer sometimes still has to know that, internally,
the default is upper case. And if the internal case has so little
significance, why should there be a religious war about it?
> If you believe what I just said, you would propose that the reader get
> an option to flip case instead of up-casing when converting from
> external representation to internal representation, and would propose
> another value for *print-case* that does the inverse transformation.
Something like this was suggested in the "discussion" section of
READ-CASE-SENSITIVITY (Version 1). But maybe it shouldn't just
flip everything:
An interesting possibility would be to disguise the preferred
internal case by defining a value for *READ-CASE* called :INVERT.
If the value were :INVERT, mixed-case symbols would remain the same
(or perhaps they would be inverted too) but all-upper-case input
would specify a lower-case name internally, and vice versa.
One problem with such proposals is that (I suspect) most people
most of the time will write code in lower case. Having the reader
always invert what they type seems a bit perverse. I'd be surprised
if this convinced anyone to change their mind, though.
> This would be compatible with everybody, would make everybody happy
> except for those who might insist that one internal representation
> is better than the other, and hopefully would avoid spending a lot
> of time on discussion. What do you think?
I'd prefer to change the internal case, but this is a reasonable
alternative if a change can't happen or would cause hard feelings
or extensive difficulty if it did.
∂17-Mar-89 1046 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL (Version 9)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 17 Mar 89 10:46:17 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa08933; 17 Mar 89 18:26 GMT
Date: Fri, 17 Mar 89 18:25:09 GMT
Message-Id: <5014.8903171825@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: issue PROCLAIM-LEXICAL (Version 9)
To: "David A. Moon" <Moon@scrc-stony-brook.arpa>, masinter.pa@xerox.com
In-Reply-To: David A. Moon's message of Thu, 16 Mar 89 12:29 EST
Cc: cl-cleanup@sail.stanford.edu
> Maybe I shouldn't take this attitude, but I will anyway. I have brief
> notes on the amendments that were proposed, but since I think all of them
> were wrongheaded and braindamaged, I'm not going to help anyone remember
> them. Only one of the amendments was actually voted on, so we're certainly
> free to forget the other two.
I didn't much like the ammendments either. They were drafted on the
spot and probably not very well thought-out.
However, it would be nice to know if there are still strong objections
to version 9 (and what they are if they exist) so there will be time
to consider them before the meeting.
∂17-Mar-89 1100 CL-Cleanup-mailer Issue: CONDITION-RESTARTS (Version 1)
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Mar 89 11:00:09 PST
Received: from ISABEL-PERON.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 182335; Fri 17-Mar-89 13:54:53 EST
Date: Fri, 17 Mar 89 13:57 EST
From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
Subject: Issue: CONDITION-RESTARTS (Version 1)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <890314-082536-2261@Xerox>
Message-ID: <19890317185733.7.MLY@ISABEL-PERON.AI.MIT.EDU>
Date: 14 Mar 89 08:24 PST
From: masinter.pa@xerox.com
Your thoughts?
----- Begin Forwarded Messages -----
[...]
The proposal doesn't compensate for the mistake of having
disassociated restarts from context in the first place.
All restarts should have associated with them a real predicate
(not just a screwy wired-in (lambda (c) (eq c associated-condition)))
In general the applicability of a restart depends on the dynamic
environment in which it invoked as well as that in which it
was established.
All restarting forms should require a condition argument (-not- NIL.)
Why on earth do ABORT, USE-VALUE, etc still exist?
The business about COPY-CONDITION is completely confused.
I don't care for the syntax, though it isn't worse than
that of the rest of the condition system.
∂17-Mar-89 1101 CL-Cleanup-mailer Issue: CONDITION-RESTARTS (Version 1)
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Mar 89 11:01:07 PST
Received: from ISABEL-PERON.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 182336; Fri 17-Mar-89 13:55:49 EST
Date: Fri, 17 Mar 89 13:58 EST
From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
Subject: Issue: CONDITION-RESTARTS (Version 1)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <890314-082536-2261@Xerox>
Supersedes: <19890317185733.7.MLY@ISABEL-PERON.AI.MIT.EDU>
Message-ID: <19890317185835.8.MLY@ISABEL-PERON.AI.MIT.EDU>
From: masinter.pa@xerox.com
Subject: Issue: CONDITION-RESTARTS (Version 1)
To: Richard Mlynarik <Mly@ai.ai.mit.edu>, Daniels.PA@xerox.com
Reply-To: cl-cleanup@sail.stanford.edu
Your thoughts?
----- Begin Forwarded Messages -----
[...]
The proposal doesn't compensate for the mistake of having
disassociated restarts from context in the first place.
All restarts should have associated with them a real predicate
(not just a screwy wired-in (lambda (c) (eq c associated-condition)))
In general the applicability of a restart depends on the dynamic
environment in which it invoked as well as that in which it
was established.
All restarting forms should require a condition argument (-not- NIL.)
Why on earth do ABORT, USE-VALUE, etc still exist?
The business about COPY-CONDITION is completely confused.
I don't care for the syntax, though it isn't worse than
that of the rest of the condition system.
∂17-Mar-89 1205 CL-Cleanup-mailer Issue: IN-SYNTAX (Version 1)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:05:22 PST
Received: from fafnir.think.com by Think.COM; Fri, 17 Mar 89 15:01:32 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 17 Mar 89 15:02:43 EST
Received: by verdi.think.com; Fri, 17 Mar 89 14:59:31 EST
Date: Fri, 17 Mar 89 14:59:31 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903171959.AA09035@verdi.think.com>
To: masinter.pa@xerox.com
Cc: KMP@stony-brook.scrc.symbolics.com, CL-Cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@xerox.com's message of 16 Mar 89 23:05 PST <890316-230556-6907@Xerox>
Subject: Issue: IN-SYNTAX (Version 1)
Yet Another Puppy--YAP!
So let us define a "yapper" to mean someone who proposes Yet Another Puppy.
--Q
∂17-Mar-89 1214 CL-Cleanup-mailer Issue LOOP-AND-DISCREPANCY, version 1
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:14:03 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01428g; Wed, 15 Mar 89 23:55:31 PST
Received: by bhopal id AA11642g; Wed, 15 Mar 89 23:56:18 PST
Date: Wed, 15 Mar 89 23:56:18 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8903160756.AA11642@bhopal>
To: gls@Think.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Guy Steele's message of Wed, 15 Mar 89 13:50:51 EST <8903151850.AA02865@verdi.think.com>
Subject: Issue LOOP-AND-DISCREPANCY, version 1
The document 89-004 followed what the code does (the "code" being that
portable version that used to come from MIT), but at the Hawaii meeting,
I remember suggesting that it ought to be made formal as to whether or not
the WITH or the FOR/AS is to be repeated. I'm glad you took the time to
write up the issue (which I approve of). It's really a very minor point,
so there is very little risk involved.
-- JonL --
∂17-Mar-89 1214 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:14:13 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01417g; Wed, 15 Mar 89 23:39:01 PST
Received: by bhopal id AA11617g; Wed, 15 Mar 89 23:39:49 PST
Date: Wed, 15 Mar 89 23:39:49 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8903160739.AA11617@bhopal>
To: gls@Think.COM
Cc: masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu
In-Reply-To: Guy Steele's message of Tue, 28 Feb 89 14:13:37 EST <8902281913.AA03555@verdi.think.com>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
re: I conclude that the strict interpretation may be preferred, but not for the
reasons Jonl has advanced! The liberal interpretation does *not* prevent
compilers for stock hardware from producing good code, and therefore the
code example does not support his claim to the contrary.
Guy, I fear that you have made an error of logic in analyzing my example.
You use the "strict" interpretation to conclude that the example is
incorrect code (as it should be!); but the whole point of the example is
to show that under the "liberal" interpretation, it's correctness depends
on the implementation rather than on a implementation-independent definition.
If you don't see this, then perhaps we should talk about it "off line".
-- JonL --
∂17-Mar-89 1214 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:14:37 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01413g; Wed, 15 Mar 89 23:32:00 PST
Received: by bhopal id AA11607g; Wed, 15 Mar 89 23:32:47 PST
Date: Wed, 15 Mar 89 23:32:47 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8903160732.AA11607@bhopal>
To: cl-cleanup@sail.stanford.edu
Cc: X3J13@Sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 15 Mar 89 05:13 PST <890315-051405-3472@Xerox>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Although I haven't had time to join the overly-lengthy discussion on this
matter, I did point out one particularly confusing direction -- that this
proposal to "fix" the function ADJUST-ARRAY has become a proposal to alter
the semantics of the type SIMPLE-ARRAY. Compare CLtL, p28, with the
sentence in the Rationale Section:
"Specifying the points left unspecified (requiring all simple arrays to be
non-adjustable and all adjustable arrays to be non-simple) would require
large changes to some implementations and would be of little benefit to
..."
and with an item in the Clarification section:
"a. Whether an array can be both simple and adjustable is unspecified."
[CLtL definition *does* specify it].
I suggested that a simple statement be added to the proposal as follows:
"This proposal does not attempt to alter the meaning of the type
SIMPLE-ARRAY in any way"
Moon expressed approval of adding that statement.
Altered semantics would mean that it is no longer a portable type. I
have sent out several trivially small examples that show this. Some
people have interpreted those examples as simply showing what happens
with "broken" code; but quite to the contrary, they show how code can be
"correct" on one implementation and "broken" on another ****** when the
definition of SIMPLE-ARRAY is allowed to vary between one implementation
and the other ******. Very carefully, CLtL spells out that implementations
may vary on the efficiency with which they implement SIMPLE-ARRAYS; but
nowhere does it provide for optional exclusion of some parts of the
definition thereof.
Also, I note that all of the discussion on the Cl-cleanup list was by
persons other than the half-dozen or so maintainers of "stock hardware"
compilers. I personally spoke with three others (not including myself)
at Hawaii, and we all have identical requirements for the type SIMPLE-ARRAY,
and identical resolve that it must not be changed. Our compilers will
continue to offer this C-level optimization capability; the only
question is whether or not the CL1989 Standard will be cognizant of it.
-- JonL --
∂17-Mar-89 1229 CL-Cleanup-mailer DYNAMIC-EXTENT
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:27:59 PST
Received: from fafnir.think.com by Think.COM; Fri, 17 Mar 89 15:23:26 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 17 Mar 89 15:24:37 EST
Received: by verdi.think.com; Fri, 17 Mar 89 15:21:24 EST
Date: Fri, 17 Mar 89 15:21:24 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903172021.AA09135@verdi.think.com>
To: Mly@ai.ai.mit.edu
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: Richard Mlynarik's message of Fri, 17 Mar 89 13:29 EST <19890317182930.6.MLY@ISABEL-PERON.AI.MIT.EDU>
Subject: DYNAMIC-EXTENT
Date: Fri, 17 Mar 89 13:29 EST
From: Richard Mlynarik <Mly@ai.ai.mit.edu>
I don't see any way in the proposal to declare that a closure itself, rather than
its arguments, has dynamic extent. My greatest single use for dynamic-extent
declarations is to ensure stack-consing of closures.
Symbolics have a declaration SYS:DOWNWARD-FUNCTION for this case.
Perhaps CL could use DYNAMIC-EXTENT-FUNCTION
(flet ((test (a b)
(declare (dynamic-extent-function))
...))
(foo #'test))
(foo (lambda (a b)
(declare (dynamic-extent-function))
...))
This is a genuine need. I suggest
(flet ((test (a b) ...))
(declare (dynamic-fextent test)) ;So pick a better name
(foo #'test))
Another feature which I find sorely needed (and which nobody seems
to support) is a way to declare that the result of a form
has dynamic extent. For example,
(defmacro with-frob (thunk &body body)
`(let ((*frob-stack* (cons (the dynamic-extent-object ,thunk) *frob-stack*)))
(declare (dynamic-extent *frob-stack*))
,@body))
The idea is to avoid making all users of the with-frob macro
put in explicit dynamic-extent-function declarations.
This proposal has problems. It is not enough to say
"foo has dynamic extent extent". You have to say something
about when it starts and ends. For executable constructs
we implicitly refer to the time execution enters the
construct and the time execution leaves it. For objects
it is more difficult, and I claim you need to tie it to
code execution. How do I know that the "thunk" is supposed
to last for the duration of the LET, rather than just the
duration of the call to CONS, or the duration of the caller
of the macro?
--Guy
∂17-Mar-89 1254 CL-Cleanup-mailer Re: DEFAULT-CASE
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:54:27 PST
Received: from franz.UUCP by ucbarpa.Berkeley.EDU (5.61/1.33)
id AA10420; Fri, 17 Mar 89 12:23:10 -0800
Received: from frisky by franz (3.2/3.14)
id AA24300; Fri, 17 Mar 89 11:37:25 PST
Received: by frisky (3.2/3.14)
id AA11169; Fri, 17 Mar 89 11:36:17 PST
From: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
Return-Path: <frisky!jkf>
Message-Id: <8903171936.AA11169@frisky>
To: franz!ucbarpa!B.GP.CS.CMU.EDU!Scott.Fahlman
Cc: franz!sail.stanford.edu!cl-cleanup
Subject: Re: DEFAULT-CASE
In-Reply-To: Your message of Fri, 17 Mar 89 11:19:37 EST.
<8903171622.AA04031@ucbarpa.Berkeley.EDU>
Date: Fri, 17 Mar 89 11:36:14 PST
Scott,
I completely agree that all 'official' Common Lisp symbol names should
be use one case, and should there ever be a library of contributed programs
only those program that work in a case-insensitive mode should be
accepted. When Common Lisp starts up it should be case-insensitive
just like it is now.
>> I think that this is a recipe for confusion
>> and major portability problems. As soon as there is code around that
>> assumes case sensitivity, anyone who wants to use that code in conjunction
>> with code of his own has to go along with case sensitivity.
This is incorrect. I've had ten years of experience with using
code written in both case-sensitive and insensitive-modes in the same Lisp
(first it was debugging Macsyma in Franz Lisp, and now it is working
with programs like PCL in Common Lisp). The only difficulties
I had were due to the default case of symbol names (and that is what
my proposal is directed to fix). Keep in mind that if you
decide to live solely in the case-insensitive world you still have
access to all symbols, you may just have to type extra backslashes or
vertical bars sometimes.
>> We'll either have two incompatible software words within Common Lisp,
>> or it will drag us all through a major incompatible change we don't want.
I honestly don't know what you mean by this. Perhaps you could describe some
of your experiences or just some scenarios that you imagine might happen.
Keep in mind that there is already considerable freedom in
how people write programs. What if we started getting flooded with
great programs written in French, or Spanish or Italian which
many of us couldn't understand. Should we mandate that for portability
all programs shall be written in English (or perhaps Esperanto)?
What if someone developed a loop macro that half the users loved and half
despised? Should we not include that macro in Common Lisp because people
might start using it and then write code that half the users can't read
without feeling ill?
Remember, the only thing that will change if this and the
READ-CASE-SENSITIVITY proposal pass is that the default case for symbol
names will be lower. Absolutely nothing else about your world or
the way you program need change.
If you want, we can privately correspond on these issues and then
send a summary of what we've concluded to this mailing list.
- john foderaro
∂17-Mar-89 1254 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:54:39 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 559814; Fri 17-Mar-89 15:51:33 EST
Date: Fri, 17 Mar 89 15:51 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
To: Jon L White <jonl@lucid.com>
cc: cl-cleanup@sail.stanford.edu, X3J13@Sail.stanford.edu
In-Reply-To: <8903160732.AA11607@bhopal>
Message-ID: <19890317205125.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 15 Mar 89 23:32:47 PST
From: Jon L White <jonl@lucid.com>
Although I haven't had time to join the overly-lengthy discussion on this
matter, I did point out one particularly confusing direction -- that this
proposal to "fix" the function ADJUST-ARRAY has become a proposal to alter
the semantics of the type SIMPLE-ARRAY.
Adding the discussion of SIMPLE-ARRAY was at *+*YOUR*+* request, JonL.
There is !!NO!! change to the semantics, as I thought you had agreed in
the last message you sent on the topic. If now you're taking that back
and saying that you still think what this proposal says is a change to
the semantics, okay, but I have yet to figure out why you think that or
what you think is changed.
∂17-Mar-89 1257 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:57:27 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Fri, 17 Mar 89 15:52:50 EST
Date: Fri, 17 Mar 89 15:53 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
To: Jon L White <jonl@lucid.com>
Cc: cl-cleanup@sail.stanford.edu, X3J13@sail.stanford.edu
In-Reply-To: <8903160732.AA11607@bhopal>
Message-Id: <19890317205329.0.BARMAR@OCCAM.THINK.COM>
What happens in implementations that allow all arrays to be adjusted?
If you require that (typep x 'simple-array) implies (not
(adjustable-array-p x)), I see two possible resolutions: 1) such
implementations are not conforming; 2) the type SIMPLE-ARRAY is empty.
I find (1) distasteful, because non-adjustable arrays and the
SIMPLE-ARRAY type exist solely for the benefit of implementations that
need them, and this would require support of these concepts in
implementations that don't derive any benefit from them. I think (2)
makes the SIMPLE-ARRAY type pretty useless, since a portable program
can't expect anything to be of this type (FIXNUM had this problem until
we fixed it in Hawaii).
barmar
∂17-Mar-89 1327 CL-Cleanup-mailer DYNAMIC-EXTENT
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Mar 89 13:27:36 PST
Received: from ISABEL-PERON.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 182401; Fri 17-Mar-89 16:22:14 EST
Date: Fri, 17 Mar 89 16:24 EST
From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
Subject: DYNAMIC-EXTENT
To: gls@think.com
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <8903172021.AA09135@verdi.think.com>
Message-ID: <19890317212454.9.MLY@ISABEL-PERON.AI.MIT.EDU>
Date: Fri, 17 Mar 89 15:21:24 EST
From: Guy Steele <gls@think.com>
This is a genuine need. I suggest
(flet ((test (a b) ...))
(declare (dynamic-fextent test)) ;So pick a better name
(foo #'test))
A declaration in the body of the function feels preferable to me
as a user -- otherwise it is necessary to create a name for a function
simply to declare something about it. There may indeed be semantic
reasons to decide otherwise.
Another feature which I find sorely needed (and which nobody seems
to support) is a way to declare that the result of a form
has dynamic extent.
This proposal has problems. It is not enough to say
"foo has dynamic extent extent". [...]
Forget it. I was confused (probably by the fact that I use a lisp
implementation which has a dynamic-extent declaration within closures
but no general dynamic-extent declaration in the sense of the proposal.)
I should have written my sample macro as
(defmacro with-frob (thunk &body body)
(let ((tem (gensym)))
`(let ((,tem ,thunk))
(declare (dynamic-extent ,tem))
(let ((*frob-stack* (cons ,tem *frob-stack*)))
...))))
where I assume that the implementation knows to stack-allocate the `y' in
(let* ((foo 1)
(y (lambda () foo)))
(declare (dynamic-extent y))
... y ...)
∂17-Mar-89 1337 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 13:37:36 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 559887; Fri 17-Mar-89 16:33:57 EST
Date: Fri, 17 Mar 89 16:33 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
To: Jon L White <jonl@lucid.com>, Masinter.pa@Xerox.com
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8903160732.AA11607@bhopal>
Message-ID: <19890317213333.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
This version is edited to reflect the changes I think JonL wants,
which I had thought were already in. I'll mail this to X3J13 to
supersede version 8, unless one of you asks me not to. That would
probably be more constructive than the intemperate message I already
sent.
Issue: ADJUST-ARRAY-NOT-ADJUSTABLE
References: ADJUST-ARRAY (p297), ADJUSTABLE-ARRAY-P (p293),
MAKE-ARRAY (pp286-289), simple arrays (p28, 289)
Category: CLARIFICATION
Edit history: 22-Apr-87, Version 1 by Pitman
15-Nov-88, Versions 2a,2b,2c by Pitman
02-Dec-88, Version 3 by Pitman
11-Jan-89, Version 4 by Pitman
16-Jan-89, Version 5, by Gabriel. Amended at the meeting to shorten.
23-Jan-89, Version 6, by Moon. Shorten without the bug introduced
by the amendment, add clarification of SIMPLE-ARRAY type.
15-Feb-89, Version 7, by Pitman. Minor changes per comments from
RPG and Dalton.
11-Mar-89, Version 8, by Pitman. Change category, add endorsements.
17-Mar-89, Version 9, by Moon, fix wording and examples to make it
clear that the semantics of simple-array is unchanged.
Problem Description:
The description of the :ADJUSTABLE option to MAKE-ARRAY on p288
says that ``the argument, if specified and not NIL, indicates that
it must be possible to alter the array's size dynamically after
it is created. This argument defaults to NIL.''
The description of the :ADJUSTABLE option does not say what
MAKE-ARRAY will do if the argument is unsupplied or explicitly NIL.
The description of ADJUSTABLE-ARRAY-P on p293 says that it is
true ``if the argument (which must be an array) is adjustable, and
otherwise false.'' However, the description of MAKE-ARRAY makes
it clear that this is not necessarily the same as asking if
the array was created with :ADJUSTABLE T. If ADJUSTABLE-ARRAY-P
returns NIL, you know that :ADJUSTABLE NIL was supplied (or no
:ADJUSTABLE option was supplied), but if ADJUSTABLE-ARRAY-P returns
T, then there is no information about whether :ADJUSTABLE was used.
The description of ADJUST-ARRAY on pp297-298 says that it is
``not permitted to call ADJUST-ARRAY on an array that was not
created with the :ADJUSTABLE option.'' This is inconsistent with
ADJUSTABLE-ARRAY-P.
A problem which comes up in practice is that some programmers
expect runtime error checking if they have done
(MAKE-ARRAY ... :ADJUSTABLE NIL) and they later try to adjust
the array using ADJUST-ARRAY.
The definition of the SIMPLE-ARRAY type and its subtypes needs
clarification of its relationship to adjustability.
Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE:CLARIFY):
1. ADJUSTABLE-ARRAY-P is true of all arrays created with a true
:ADJUSTABLE option to MAKE-ARRAY. Whether ADJUSTABLE-ARRAY-P is
true of some other arrays is unspecified.
2. If MAKE-ARRAY is called with the :ADJUSTABLE, :FILL-POINTER,
and :DISPLACED-TO arguments each either unspecified or false, the
resulting array is a simple array. (This just repeats what CLtL
says on page 289, it's here to aid in understanding the next point.)
3. If MAKE-ARRAY is called with one or more of the :ADJUSTABLE,
:FILL-POINTER, or :DISPLACED-TO arguments true, whether the
resulting array is simple is unspecified.
4. ADJUST-ARRAY ``should signal'' an error if ADJUSTABLE-ARRAY-P
of its first argument is false. ADJUST-ARRAY must not signal an
`array not adjustable' error if ADJUSTABLE-ARRAY-P of its first
argument is true.
5. The value of ADJUSTABLE-ARRAY-P on a simple array is unspecified.
Note: ``should signal'' is taken from the new error terminology.
It means that in ``safe code'' (code compiled with highest safety)
an error must be signalled, but that in unsafe code (code not compiled
with highest safety), an error might or might not be signalled.
Clarifications and Logical Consequences:
a. Whether an array can be both simple and adjustable is unspecified.
b. There is no specified way to create an array for which ADJUSTABLE-ARRAY-P
definitely returns NIL.
c. There is no specified way to create an array that is non-simple.
d. This legitimizes ADJUSTABLE-ARRAY-P as an appropriate predicate to
determine whether ADJUST-ARRAY will reliably succeed.
e. If ADJUST-ARRAY is invoked on an array that was created without
supplying :ADJUSTABLE true, an `array not adjustable' error
``should be signalled'' unless ADJUSTABLE-ARRAY-P returns true on
that array (in which case it must not signal an `array not adjustable'
error).
f. There is no change to the meaning of the type SIMPLE-ARRAY, only
a clarification that a conforming program cannot assume that any
array is not simple.
Rationale:
This effectively makes the status quo explicit. This preserves the
raison d'etre of simple arrays, which is to provide a portable interface
to implementation-dependent specialized arrays that trade decreased
functionality for faster access.
A proposed alternative was to specify a way to create an array that is
guaranteed not to be simple. This would have required large changes
to some implementations and would be of little benefit to users.
Users need to know that certain arrays are simple, so they can put in
declarations and get higher performance, but users have no need to be
able to create arrays that are definitely non-simple (for lower
performance) or definitely non-adjustable (to cause errors).
Examples:
1. The following program is conforming. It is unspecified which branch
of the IF it follows.
(defun double (a)
(if (adjustable-array-p a)
(adjust-array a (* (length a) 2))
(let ((new (make-array (* (length a) 2))))
(replace new a :end1 (length a))
new)))
(double (make-array 30))
2. The following program is conforming. In no implementation is the
type declaration violated.
(let ((a (make-array 100)))
(declare (simple-array a))
(frob a))
3. The following program is non-conforming. The consequences of this
program are undefined because the type declaration is violated in some
valid implementations.
(let ((a (make-array 100 :adjustable t)))
(declare (simple-array a))
(frob a))
Current Practice:
Probably everyone is compatible with this proposal.
Symbolics Genera makes :ADJUSTABLE NIL arrays adjustable in most cases,
and ignores adjustability in deciding whether an array is simple,
and is compatible with this proposal.
Lucid, IIM, and Symbolics Cloe make :ADJUSTABLE NIL arrays non-adjustable
in all cases, and make all arrays non-simple unless the Common Lisp
language requires them to be simple, and are compatible with this proposal.
Cost to Implementors:
It's in principle possible that some implementation would have to change,
but in practice there are no known implementations that would have to change.
Cost to Users:
None. This is a fully compatible change from the user's standpoint.
Benefits:
Users would know what to expect.
Non-Benefits:
Users who expect adjusting arrays created with :ADJUSTABLE NIL to signal
an error would not get the desired error checking.
Aesthetics:
Most people believe the status quo is unaesthetic. Having an aspect of
the language explicitly unspecified is more aesthetic than having it
implicitly unspecified on account of vague or inconsistent documentation.
Discussion:
Pitman, Moon, Gabriel, and Steele support this amended proposal.
MACSYMA ran into portability problems due to the status quo.
If the issue had been documented, that would have helped.
Encouraging implementations that are able to at least make
(MAKE-ARRAY ... :ADJUSTABLE NIL) create non-adjustable arrays
where possible would help, too.
We considered proposals to incompatibly change this primitive in a
variety of ways, but the community was very split with strong proponents
and opponents of each alternate proposal.
The overriding concern driving this proposal is that Symbolics
has asserted that most of the other really interesting proposals would
likely involve a sizable cost to implementors (and their installed bases)
to implement what were judged by some as gratuitous changes from the
status quo.
Pitman wishes some of the other proposals were economically feasible to
pursue but reluctantly agrees that maintaining (and clearly documenting)
the status quo is probably the most reasonable avenue left to us.
∂17-Mar-89 1346 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 13:45:46 PST
Received: from fafnir.think.com by Think.COM; Fri, 17 Mar 89 16:41:06 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 17 Mar 89 16:42:07 EST
Received: by verdi.think.com; Fri, 17 Mar 89 16:38:55 EST
Date: Fri, 17 Mar 89 16:38:55 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903172138.AA09505@verdi.think.com>
To: jonl@lucid.com
Cc: gls@Think.COM, masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu
In-Reply-To: Jon L White's message of Wed, 15 Mar 89 23:39:49 PST <8903160739.AA11617@bhopal>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
Date: Wed, 15 Mar 89 23:39:49 PST
From: Jon L White <jonl@lucid.com>
re: I conclude that the strict interpretation may be preferred, but not for the
reasons Jonl has advanced! The liberal interpretation does *not* prevent
compilers for stock hardware from producing good code, and therefore the
code example does not support his claim to the contrary.
Guy, I fear that you have made an error of logic in analyzing my example.
You use the "strict" interpretation to conclude that the example is
incorrect code (as it should be!); but the whole point of the example is
to show that under the "liberal" interpretation, it's correctness depends
on the implementation rather than on a implementation-independent definition.
If you don't see this, then perhaps we should talk about it "off line".
I respectfully disagree with your assessment; I believe that you have
erred in analyzing my analysis. Specifically, I do *not* conclude
that the example is incorrect code. Let me quote further from my
message of Feb 28:
I argue that the program is correct under both interpretations....
Under the strict interpretation implementation (A) is incorrect by
definition. Under the liberal interpretation implementation (A) is
correct, and accomplishes a useful purpose. ...
According to my analysis, the correctness of the code does not depend
on the choice of strict or liberal interpretation; rather, the
correctness of implementation (A) depends on the choice of interpretation.
I conclude: (1) Under the strict interpretation only some
implementations are correct, but under the liberal interpretation many
more are correct. (2) You can get good code on stock hardware
regardless of the choice of interpretation.
Therefore unless some other argument can be advanced for the strict
interpretation, the liberal interpretation is to be preferred because it
invalidates fewer implementation strategies.
So there you have a concise summary of my argument that may make it
easier for you to find the hole in it (if any).
--Guy
∂17-Mar-89 1410 CL-Cleanup-mailer Re: Issue: EXPT-ZERO-ZERO (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 14:10:35 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 559948; Fri 17-Mar-89 17:07:44 EST
Date: Fri, 17 Mar 89 17:07 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: EXPT-ZERO-ZERO (Version 1)
To: masinter.pa@Xerox.COM
cc: KMP@symbolics.com, CL-Cleanup@sail.stanford.edu,
Cyphers@JASPER.SCRC.Symbolics.COM
In-Reply-To: <890316-211042-6708@Xerox>
Message-ID: <890317170725.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: 16 Mar 89 21:10 PST
From: masinter.pa@Xerox.COM
Kent, do you want to proceed with this one? I don't think it is necessary
or even a good idea. What do other programming languages do?
If you do, I think we should leave (EXPT 0 0) = 1 and (EXPT 0.0 0) = 1 and
only deal with (EXPT 0.0 0.0) and (EXPT 0 0.0).
Let's table it.
I asked a bunch of the people here about it and they didn't really buy
all the arguments advanced for why it was such a good idea to have 1
come out, but they didn't really care a lot since it was pretty easy to
special case zero before it ever got into EXPT in the first place.
Doesn't this fit into the ERRORS-IN-NUMBERS-CHAPTER spectrum?
If we were going to pursue it, I guess it could.
∂17-Mar-89 1541 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 15:40:34 PST
Received: from fafnir.think.com by Think.COM; Fri, 17 Mar 89 16:23:16 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 17 Mar 89 16:24:05 EST
Received: by verdi.think.com; Fri, 17 Mar 89 16:20:53 EST
Date: Fri, 17 Mar 89 16:20:53 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903172120.AA09400@verdi.think.com>
To: jonl@lucid.com
Cc: cl-cleanup@sail.stanford.edu, X3J13@sail.stanford.edu
In-Reply-To: Jon L White's message of Wed, 15 Mar 89 23:32:47 PST <8903160732.AA11607@bhopal>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Date: Wed, 15 Mar 89 23:32:47 PST
From: Jon L White <jonl@lucid.com>
...
Also, I note that all of the discussion on the Cl-cleanup list was by
persons other than the half-dozen or so maintainers of "stock hardware"
compilers. I personally spoke with three others (not including myself)
at Hawaii, and we all have identical requirements for the type SIMPLE-ARRAY,
and identical resolve that it must not be changed. Our compilers will
continue to offer this C-level optimization capability; the only
question is whether or not the CL1989 Standard will be cognizant of it.
I am very concerned about the stock hardware, but also very confused.
I understand that the stock-hardware implementors adamantly oppose
the proposed change, but I still have not seen a single convincing
example of why the proposed change would prevent them from accomplishing
the desired optimizations or why the proposed change would defeat
portability. I acknowledge that JonL has provided an example or two,
but I have not found them convincing. So either these examples are
wrong, or I am badly wedged; in either case I need further explanation.
--Guy
∂17-Mar-89 1555 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89 15:55:19 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02075g; Fri, 17 Mar 89 15:47:55 PST
Received: by bhopal id AA19349g; Fri, 17 Mar 89 15:50:11 PST
Date: Fri, 17 Mar 89 15:50:11 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8903172350.AA19349@bhopal>
To: gls@Think.COM
Cc: masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu
In-Reply-To: Guy Steele's message of Fri, 17 Mar 89 16:38:55 EST <8903172138.AA09505@verdi.think.com>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
re: Under the strict interpretation implementation (A) is incorrect by
definition. Under the liberal interpretation implementation (A) is
correct, and accomplishes a useful purpose. ...
Guy, I'm totally confused by your "analysis" now; the whole point of
the example is to show that portability is sacrificed under what you are
calling the "liberal" interpretation -- that altering the CLtL semantics
of SIMPLE-ARRAY makes it non portable. As I look back into your
previous msg, I see that you did say:
Now, the two implementations behave differently on the example, and that
is a cause for concern.
Also, your statement just quoted above shows the variations possible under
implementation (A) and (B), thus reiterating the non-portability question
I brought up. Thus you'll have to admit that my example showed *exactly*
what I claimed it did.
However, I disagree with your judgement -- that it is better to accept an
interpretation that allows more variation among implementations -- because
the variation you are thereby accommodating means that the type is no longer
portable. We may be stuck with that position, but I don't agree that it
is a good thing.
-- JonL --
∂17-Mar-89 1618 CL-Cleanup-mailer Issue: CONDITION-RESTARTS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 16:18:28 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560081; Fri 17-Mar-89 19:15:40 EST
Date: Fri, 17 Mar 89 19:15 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CONDITION-RESTARTS (Version 1)
To: Richard Mlynarik <Mly@AI.AI.MIT.EDU>, KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <19890317185835.8.MLY@ISABEL-PERON.AI.MIT.EDU>
Message-ID: <19890318001531.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 17 Mar 89 13:58 EST
From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
The proposal doesn't compensate for the mistake of having
disassociated restarts from context in the first place.
All restarts should have associated with them a real predicate
(not just a screwy wired-in (lambda (c) (eq c associated-condition)))
In general the applicability of a restart depends on the dynamic
environment in which it invoked as well as that in which it
was established.
You're absolutely right. In all the hoopla I had forgotten about this.
I think it's quite reasonable to have some convenient syntax for the
common case where the predicate is to test for a particular condition
object, but the underlying primitives should allow an arbitrary
predicate. RESTART-BIND needs to be enhanced with a :TEST argument,
which is a predicate function that COMPUTE-RESTARTS calls.
All restarting forms should require a condition argument (-not- NIL.)
I disagree with this, because it does make sense to restart a program
in response to some situation other than the signalling of a condition.
Why on earth do ABORT, USE-VALUE, etc still exist?
I don't know either.
The business about COPY-CONDITION is completely confused.
I agree with this. The argument against resignalling a condition
is wrong; there is no confusion of identity if a condition is signalled,
this results in some transfer of control, and then the same condition
object, representing the same situation that is still happening, is
signalled again. There is also no harm in a system keeping a particular
pre-created condition object around and using that same object every
time it signals a particular condition, so long as it keeps its restarts
straight. Since it is the program that signals a condition that
establishes restarts bound to that particular condition, it knows what
it is doing, and if it knows that it doesn't establish any restarts
that are associated to the particular condition object, it knows there
is no harm in reusing the condition object.
I don't care for the syntax, though it isn't worse than
that of the rest of the condition system.
I don't like the syntax in the version that got mailed to X3J13, which
I don't think was really ready for mailing. I had some alternate syntax
proposals, but I don't much like them either.
Here is what I would suggest doing to the proposal to make it ready
for X3J13:
1. Define that it is an error for SIGNAL to be called on a condition
more than once.
2. Introduce a function COPY-CONDITION
Remove items 1 and 2.
Add a :TEST argument to RESTART-BIND.
Add a :TEST argument to RESTART-CASE.
3. Introduce a macro WITH-CONDITION-RESTARTS
If we can't think of a better syntax for this, leave it out. It can
always be done, awkwardly, by first making the condition object and
binding it to a variable, then doing a RESTART-CASE with :TEST predicates
that check for the condition being that one and with the expression
just being a call to SIGNAL of that condition.
4. Extend COMPUTE-RESTARTS, FIND-RESTART, ABORT, CONTINUE, USE-VALUE,
and STORE-VALUE to permit an optional condition object as an argument.
OK.
5. Add two new macros SIGNAL-WITH-RESTARTS and ERROR-WITH-RESTARTS:
Same comment as #3.
6. Define that Common Lisp macros such as CHECK-TYPE, which are defined
to signal and to make restarts available, use the equivalent of
WITH-CONDITION-RESTARTS to associate the conditions they signal with
the defined restarts, so that users can make reliable tests not only
for the restarts being available, but also for them being available
for the right reasons.
OK (except don't use the name WITH-CONDITION-RESTARTS).
∂17-Mar-89 1627 CL-Cleanup-mailer Issue: PACKAGE-FUNCTION-CONSISTENCY (version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 16:26:59 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560089; Fri 17-Mar-89 19:24:33 EST
Date: Fri, 17 Mar 89 19:24 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-FUNCTION-CONSISTENCY (version 4)
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <890317-102812-1247@Xerox>
Message-ID: <19890318002424.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
I think this one is more correct than the one Larry mailed
to X3J13, in its reflection of the amendments voted in at
the last meeting. I'll mail it to X3J13 if no one disagrees.
!
Issue: PACKAGE-FUNCTION-CONSISTENCY
References: 11.7 Package System Functions and Variables (pp182-188)
Category: CLARIFICATION/CHANGE
Edit history: 21-Oct-88, Version 1 by Pitman
12-Jan-89, Version 2 by Masinter (add MORE-PERMISSIVE option)
17-Mar-89, Version 3, by Masinter, MORE-PERMISSIVE as
amended & adopted at Jan 89 X3j13
17-Mar-89, Version 4, by Moon, correct amended wording
Problem Description:
CLtL is vague about whether either or both of package or package name
are permissible in some cases.
Proposal (PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE):
Clarify that it is permissible to pass either a package object
or a package name (symbol or string) in the following situations:
- the :USE argument to MAKE-PACKAGE or IN-PACKAGE
- the first argument to IN-PACKAGE, FIND-PACKAGE, RENAME-PACKAGE
or DELETE-PACKAGE
- the second argument to INTERN, FIND-SYMBOL, UNINTERN
- the second argument to EXPORT, UNEXPORT, IMPORT,
SHADOWING-IMPORT, and SHADOW
- the first argument (or a member of the list which is the first
argument) to USE-PACKAGE or UNUSE-PACKAGE.
- all package-name arguments in DEFPACKAGE except for the name and
nicknames of the package being defined.
- the first argument to PACKAGE-NAME, PACKAGE-NICKNAMES,
PACKAGE-USE-LIST, or PACKAGE-USED-BY-LIST
- the PACKAGE argument to DO-SYMBOLS.
- the PACKAGE argument to DO-EXTERNAL-SYMBOLS.
- the PACKAGE argument to DO-ALL-SYMBOLS.
If FIND-PACKAGE is given a package object as an argument, it simply
returns it.
Clarify that the function MAKE-PACKAGE permits only a package name
as an argument since it does not make sense to create an existing
package.
Clarify that package nicknames must always be expressed as package
names (symbols or strings) and may never be actual package objects.
In the list above, IN-PACKAGE may be changed to SELECT-PACKAGE
if IN-PACKAGE-FUNCTIONALITY:NEW-MACRO passes.
Examples:
(INTERN "FOO" "KEYWORD") => :FOO
(DEFVAR *FOO-PACKAGE* (MAKE-PACKAGE "FOO"))
(RENAME-PACKAGE "FOO" "FOO0")
(PACKAGE-NAME *FOO-PACKAGE*) => "FOO0"
(PACKAGE-NAME "SYS") might return "SYSTEM".
Rationale:
This makes things more consistent.
It also adds a generally useful capability.
Current Practice:
Symbolics Genera & Lucid permit strings as package names.
Symbolics Cloe does not permit strings as package names.
In Lucid FIND-PACKAGE and IN-PACKAGE require names.
Cost to Implementors:
Small.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Implementations would continue to vary gratuitously, leaving a potential
for portability problems.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
This makes things more regular, and so presumably more aesthetic.
Discussion:
Pitman ran across this problem while trying to port Macsyma to various
implementations. Discussion with other maintainers of portable programs
shows this is a common source of aggravation in portable code.
It would be possible to say that MAKE-PACKAGE took package objects as
arguments and just returned that package. That might have limited
usefulness on rare occasions, but mostly seemed too far out in left
field to bother suggesting it.
∂17-Mar-89 1600 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89 16:00:33 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02088g; Fri, 17 Mar 89 15:53:13 PST
Received: by bhopal id AA19366g; Fri, 17 Mar 89 15:55:29 PST
Date: Fri, 17 Mar 89 15:55:29 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8903172355.AA19366@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu, X3J13@Sail.stanford.edu
In-Reply-To: David A. Moon's message of Fri, 17 Mar 89 15:51 EST <19890317205125.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
re: Adding the discussion of SIMPLE-ARRAY was at *+*YOUR*+* request, JonL.
Sorry, Dave, I only ever made a request to add precisely the one statement
that you have already now added -- that the proposal *does not* alter
the CLtL semantics of SIMPLE-ARRAY. What I critiqued were statements
of the proposal that under reasonable interpretation could be taken to
mean that the CLtL p.28 definition of SIMPLE-ARRAY is being abrogated.
At any rate, thanks for the one-line addition.
-- JonL --
∂17-Mar-89 1613 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89 16:13:52 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02119g; Fri, 17 Mar 89 16:06:33 PST
Received: by bhopal id AA19436g; Fri, 17 Mar 89 16:08:50 PST
Date: Fri, 17 Mar 89 16:08:50 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8903180008.AA19436@bhopal>
To: barmar@Think.COM
Cc: cl-cleanup@sail.stanford.edu, X3J13@sail.stanford.edu
In-Reply-To: Barry Margolin's message of Fri, 17 Mar 89 15:53 EST <19890317205329.0.BARMAR@OCCAM.THINK.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
re: I find (1) distasteful, because non-adjustable arrays and the
SIMPLE-ARRAY type exist solely for the benefit of implementations that
need them, and this would require support of these concepts in
implementations that don't derive any benefit from them.
Barry, SIMPLE-ARRAY is certainly not the only concept in CLtL that exists
"solely for the benefit of implementations that [can really use it]". I
know that numerous array capabilities are present but not very useful
in Lucid Common Lisp primarily for compatiblity with Lisp Machine stuff.
That's the price to pay for portability. It just may be that we will have
to confess that we didn't succeed at portability in some areas of CL.
-- JonL --
∂17-Mar-89 1657 CL-Cleanup-mailer Issue: FIXNUM-NON-PORTABLE, v.5
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 16:57:14 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560137; Fri 17-Mar-89 19:54:04 EST
Date: Fri, 17 Mar 89 19:53 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FIXNUM-NON-PORTABLE, v.5
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <890316-220933-6804@Xerox>
Message-ID: <19890318005344.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 16 Mar 89 21:51 PST
From: masinter.pa@Xerox.COM
This is my rewrite to capture the 'intent' of the amendment
at the January X3J13. I say 'intent' because the relation
between MOST-POSITIVE-FIXNUM (which is an inclusive bound)
and ARRAY-DIMENSION-LIMIT (which is an exclusive bound) is not
> but rather (>= MOST-POSITIVE-FIXNUM (1- ARRAY-DIMENSION-LIMIT)).
No, the amendment was (<= ARRAY-DIMENSION-LIMIT MOST-POSITIVE-FIXNUM),
and this was not a mistake nor an off-by-one error. What you've
put in the proposal here is incorrect, I think. I think it was
fully intended that not only every valid array index and every
array dimension, but also array-dimension-limit itself would be
a fixnum. Someone might want to write an arithmetic iteration
whose upper bound was array-dimension-limit.
∂17-Mar-89 1656 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 16:56:32 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Fri, 17 Mar 89 19:52:28 EST
Date: Fri, 17 Mar 89 19:53 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
To: Jon L White <jonl@lucid.com>
Cc: cl-cleanup@sail.stanford.edu, X3J13@sail.stanford.edu
In-Reply-To: <8903180008.AA19436@bhopal>
Message-Id: <19890318005322.4.BARMAR@OCCAM.THINK.COM>
Date: Fri, 17 Mar 89 16:08:50 PST
From: Jon L White <jonl@lucid.com>
re: I find (1) distasteful, because non-adjustable arrays and the
SIMPLE-ARRAY type exist solely for the benefit of implementations that
need them, and this would require support of these concepts in
implementations that don't derive any benefit from them.
Barry, SIMPLE-ARRAY is certainly not the only concept in CLtL that exists
"solely for the benefit of implementations that [can really use it]". I
know that numerous array capabilities are present but not very useful
in Lucid Common Lisp primarily for compatiblity with Lisp Machine stuff.
That's the price to pay for portability. It just may be that we will have
to confess that we didn't succeed at portability in some areas of CL.
-- JonL --
The general rule has been that implementations that don't need (or don't
provide) these types of optimizations can safely ignore the language
features that support them. Some implementations can optimize array
access by knowing that the array can't be adjusted; other
implementations should not be required to remember this information if
they don't need it. Quoting from CLtL: "features that are useful only
on certain 'ordinary' or 'commercial' processors are avoided or made
optional."
Any feature of the language that provides access to facets of the
implementation allows somewhat non-portable code, meaning that it is
possible to write conforming code that produces different results in
different implementations. The simple program (PROGN
MOST-POSITIVE-FIXNUM) is conforming but produces many different results,
although the program (TYPEP MOST-POSITIVE-FIXNUM 'FIXNUM) is guaranteed
to return T in all conforming implementations. To paraphrase Moon, it
would be wonderful if all conforming programs were portable, but that's
unrealistic (it would be like expecting the grammar of a language to
only permit sensible sentences to be formed -- I suspect Godel's
Incompleteness Theorem comes into play here, pointing out that if the
grammar allows you to say everything you'd want to say, it must also
include some nonsense). The best I think we can do is provide enough
tools in the language to allow programs to detect implementation
differences and deal with them.
One thing that would help me is if you would post an example of code
that you feel is affected by this issue. I think you described such
things to me in words at the last meeting, but I (like GLS) am having a
hard time figuring out precisely what the problem is (I had the same
difficulty with the FIXNUM stuff that started the moby flame session in
the car on the way to the Japanese restaurant).
barmar
∂17-Mar-89 1839 CL-Cleanup-mailer Re: Issue: FIXNUM-NON-PORTABLE, v.5
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 18:39:40 PST
Received: from Semillon.ms by ArpaGateway.ms ; 17 MAR 89 18:09:23 PST
Date: 17 Mar 89 18:02 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: FIXNUM-NON-PORTABLE, v.5
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Fri, 17 Mar 89 19:53 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: masinter.pa@Xerox.COM, cl-cleanup@sail.stanford.edu
Message-ID: <890317-180923-2962@Xerox>
OK, I'll fix it. Thanks.
Larry
∂17-Mar-89 1949 CL-Cleanup-mailer Re: Issue: CONDITION-RESTARTS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 19:49:18 PST
Received: from Semillon.ms by ArpaGateway.ms ; 17 MAR 89 19:24:08 PST
Date: 17 Mar 89 19:23 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: CONDITION-RESTARTS (Version 1)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Fri, 17 Mar 89 19:15 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: cl-cleanup@sail.stanford.edu, Mly@AI.AI.MIT.EDU
Message-ID: <890317-192408-3127@Xerox>
I was mailing the "best draft" of all issues we want to discuss to X3J13 in
the hopes that, even if there are new proposals brought to the meeting,
they won't get the "two week" rule applied if they are minor adjustments.
Now that its less than two-weeks until the end of the meeting, I think I'll
stop trying, if the issues aren't ready.
∂17-Mar-89 2009 CL-Cleanup-mailer Issue: DEFMACRO-LAMBDA-LIST, v.2
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 20:05:27 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 17 MAR 89 19:50:34 PST
Date: 17 Mar 89 19:44 PST
From: masinter.pa@Xerox.COM
to: cl-cleanup@sail.stanford.edu
Subject: Issue: DEFMACRO-LAMBDA-LIST, v.2
Message-ID: <890317-195034-3172@Xerox>
I didn't mean to do this, but I started. It took more time
because the last writeup really presumed that &WHOLE wasn't
allowed at inner levels, so I had to mung it to change
that assumption.
However, I really think this is just a clarification of
'current practice'; I'd be suprised to find an implementation
didn't really already conform to this.
So I rewrote the cost/benefit section; do you know any
counterexamples?
!
Issue: DEFMACRO-LAMBDA-LIST
Forum: Cleanup
References: 8.1 Macro Definition (CLtL pp144-151),
Issue DESTRUCTURING-BIND
Category: CLARIFICATION/CHANGE
Edit history: 30-Jan-89, Version 1 by Pitman
17-Mar-89, Version 2 by Masinter
Problem Description:
The description of the DEFMACRO lambda list currently contains some
mis-statements and leaves some ambiguities:
1. Can &BODY, &WHOLE, and &ENVIRONMENT appear at recursive levels of the
DEFMACRO lambda list?
The description of &WHOLE (p145) specifies that &WHOLE must occur ``first
in the lambda list,'' but the description of a lambda list says that
``a lambda may [recursively] appear in place of the parameter name.''
Consequently, the question arises whether &WHOLE should be permitted to
be a synonym for &REST at inner levels of a DEFMACRO lambda list.
The descriptions of &BODY and &ENVIRONMENT do not contain syntactic
restrictions on where they may appear.
2. Does using &WHOLE affect the pattern of arguments permitted by DEFMACRO.
Proposal (DEFMACRO-LAMBDA-LIST:TIGHTEN-DESCRIPTION):
1. a. Specify that &BODY may appear at any level of a DEFMACRO lambda list.
b. Specify that &WHOLE may only appear at any level of a DEFMACRO
lambda list. At inner levels, the &WHOLE variable is bound to
the corresponding part of the argument, as with &REST, but
unlike &REST, other arguments are also allowed.
c. Specify that &ENVIRONMENT may only appear at the top level of a
DEFMACRO lambda list.
2. Clarify that using &WHOLE does not affect the pattern of arguments
specified by DEFMACRO.
Examples:
1. (DEFMACRO DM1A (&WHOLE FORM A B) ...) is defined.
(DEFMACRO DM1B (A (&WHOLE B C &OPTIONAL D) E) ...) is defined.
It allows simultaneousaccess to the THIRD of the whole
form as B and to the destructuring of that list into
C and D.
(DEFMACRO DM1C (A B &ENVIRONMENT ENV) ...) is defined.
(DEFMACRO DM1D (A (B &ENVIRONMENT ENV) C) ...) is undefined.
(DEFMACRO DM1E (A B &BODY X) ...) is defined.
(DEFMACRO DM1F (A (B &BODY X) C) ...) is defined.
2. (DEFMACRO DM2A (&WHOLE X) `',X)
(MACROEXPAND '(DM2A)) => (QUOTE (DM2A))
(MACROEXPAND '(DM2A A)) is an error.
(DEFMACRO DM2B (&WHOLE X A &OPTIONAL B) `'(,X ,A ,B))
(MACROEXPAND '(DM2B)) is an error.
(MACROEXPAND '(DM2B Q)) => (QUOTE ((DM2B Q) Q NIL))
(MACROEXPAND '(DM2B Q R)) => (QUOTE ((DM2B Q R) Q R))
(MACROEXPAND '(DM2B Q R S)) is an error.
Rationale:
1. a. An example on p151 makes it clear that this was the intent.
b. There's no cogent reason to forbid &WHOLE at inner levels.
The example on p.150 uses &WHOLE in a non-top-level position.
This simplifies the implementation of DEFMACRO if we introduce a
DESTRUCTURING-BIND which does not understand &ENVIRONMENT.
c. The environment is never different at top level than embedded.
Permitting &ENVIRONMENT to occur embedded would only encourage
the misconception that there was a potential difference.
This simplifies the implementation of DEFMACRO if we introduce a
DESTRUCTURING-BIND which does not understand &ENVIRONMENT.
2. This allows useful syntax checking.
One can always trivially write
(DEFMACRO ... (&WHOLE FORM &REST IGNORE) ...)
to get around the error checking this forces.
Current Practice:
1. a. Symbolics Genera permits &BODY at any level. This is compatible.
b. Symbolics Genera seems to permit &WHOLE at any level. When embedded,
it is treated as a synonym for &REST.
c. Symbolics Genera does not permit &ENVIRONMENT except at top level.
This is compatible.
2. Symbolics Genera has this behavior when &WHOLE appears at top level,
but not at recursive levels (where &WHOLE is treated as a synonym for
&REST).
Cost to Implementors:
This seems to be what CLtL intended and what most implementations
perform.
Cost to Users:
We think this is possibly (probably) upward compatible with most
current practice.
Cost of Non-Adoption:
Some fuzzy places in DEFMACRO continue to exist.
It's harder to introduce DESTRUCTURING-BIND because describing its relation
to DEFMACRO is difficult.
Benefits:
The language is a little tighter.
Aesthetics:
Negligible impact.
Discussion:
Part 2 of this issue came up during the discussion of DOTTED-MACRO-FORMS
but was not pursued until now.
Pitman supports these clarifications.
A previous version disallowed &WHOLE at inner levels, because
of the mistaken impression that &WHOLE was equivalent to &REST.
However, additional arguments are not allowed after &REST,
while they are for &WHOLE.
∂17-Mar-89 2126 CL-Cleanup-mailer New issue: WITH-OPEN-FILE-DOES-NOT-EXIST
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 21:25:40 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
id AA23966; Fri, 17 Mar 89 21:26:15 PST
Received: from denali.sun.com by snail.Sun.COM (4.1/SMI-4.1)
id AA08587; Fri, 17 Mar 89 21:22:28 PST
Received: from localhost by denali.sun.com (3.2/SMI-3.2)
id AA21223; Fri, 17 Mar 89 21:25:44 PST
Message-Id: <8903180525.AA21223@denali.sun.com>
To: cl-cleanup@sail.stanford.edu
Subject: New issue: WITH-OPEN-FILE-DOES-NOT-EXIST
Date: Fri, 17 Mar 89 21:25:42 PST
From: peck@Sun.COM
Really a request for an editorial change, so users will know what
to expect. A user actually reported this as a bug...
Unless someone believes that STREAM-IS-NIL is wrong, this could just
be forwarded to editorial.
Issue: WITH-OPEN-FILE-DOES-NOT-EXIST
References: CLtL page 422
Category: Clarify
Edit history: 17-Mar-89, Version 1
Problem description:
The documentation for WITH-OPEN-FILE (p 422) says:
"WITH-OPEN-FILE evaluates the Forms of the body (an implict PROGN)
with the variable Stream bound to a stream that reads or writes the
file named by the value of Filename. The options are evaluated and
used as keyword arguments to the function OPEN."
It is not clear what to do when there is no stream
"that reads or writes the file" named by Filename.
Is the body evaluated? What is Stream bound to?
Proposal: WITH-OPEN-FILE-DOES-NOT-EXIST:DONT-EVALUATE
If the result of OPEN does not return a stream (eg returns NIL)
Then the body of WITH-OPEN-FILE is not evaluated, NIL is returned.
Rationale:
The contract that "the body is evaluated with ... bound to a stream"
is maintained in the sense of a vacuous evalation.
The alternatives are:
To let the stream variable be bound to NIL (unintuitive and dangerous).
If users want to Signal-An-Error in this case, they can use
:if-does-not-exist :error
The test for (STREAMP Stream) is probably done anyway,
since the UNWIND-PROTECT cleanup form can't call CLOSE on NIL.
Proposal: WITH-OPEN-FILE-DOES-NOT-EXIST:STREAM-IS-NIL
Clarify the documentation to explain that:
Stream is bound to the value returned by OPEN.
Users of :if-does-not-exist NIL should check for a valid stream.
Rationale:
This simple to implement, no extra testing is done.
Users who use :if-does-not-exist NIL can wrap their body forms
with (when (STREAMP Stream) ...)
Examples:
1. (WITH-OPEN-FILE (foo "no-such-file" :IF-DOES-NOT-EXIST nil)
(READ foo) t)
DONT-EVALUATE: => NIL, no I/O is done, do not read from *standard-input*
STREAM-IS-NIL: => T, reads from *standard-input*
2. (WITH-OPEN-FILE (foo "/no-dir" :direction :output :IF-DOES-NOT-EXIST nil)
(format foo t) t)
DONT-EVALUATE: => NIL, no string is created.
STREAM-IS-NIL: => T, creates a string and writes to it.
Current practice:
Symbolics and Lucid apparently implement STREAM-IS-NIL.
Cost to Implementors:
STREAM-IS-NIL: no cost.
DONT-EVALUATE:
Trivial? to test for :if-does-not-exist NIL and supply a
test for (STREAMP Stream) in that case [or in every case].
Cost to Users:
DONT-EVALUATE: System tests for (STREAMP Stream), possibly extraneously.
STREAM-IS-NIL: User must write a test for (STREAMP Stream).
Probably no portable code uses :if-does-not-exist NIL without
testing explicitly for (STREAMP Stream).
Cost of non-adoption:
The current situation is non-intuitive and/or confusing.
Benefits:
Users would know if the STREAMP test has been done or whether
they must supply it.
Esthetics:
Discussion:
∂17-Mar-89 2128 CL-Cleanup-mailer Re: DEFAULT-CASE
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 21:28:18 PST
Received: from Semillon.ms by ArpaGateway.ms ; 17 MAR 89 21:25:52 PST
Date: 17 Mar 89 21:25 PST
From: masinter.pa@Xerox.COM
Subject: Re: DEFAULT-CASE
In-reply-to: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)'s
message of Thu, 16 Mar 89 12:21:57 PST
To: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
cc: CL-Cleanup@sail.stanford.EDU
Message-ID: <890317-212552-3367@Xerox>
I'm going to unilaterally declare that this issue is not a "cleanup".
If you or someone else wants to raise it at X3J13, you should request
time on the agenda to bring it up and discuss it.
∂17-Mar-89 2140 CL-Cleanup-mailer Issue: TYPE-OF-UNDERCONSTRAINED, v.5
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 21:40:20 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 560258; 18 Mar 89 00:37:50 EST
Date: Sat, 18 Mar 89 00:37 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TYPE-OF-UNDERCONSTRAINED, v.5
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <890316-175451-6328@Xerox>
Message-ID: <19890318053740.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
This version looks okay as far as making the amendments goes, but
in reading it over I noticed some problems that are really with
the original proposal. If we have to go over this issue again,
I think we should consider fixing these problems too.
(1) Why are the following types omitted from part (a), the list
of types for which TYPE-OF must be specific:
BIT-VECTOR NULL SEQUENCE
I constructed this list from 88-002R pp.1-16 and 1-17, and from the
specifications of which types are exhaustive partitions, I didn't
make it up randomly.
(2) Why are the following types omitted from part (a), the list
of types for which TYPE-OF must be specific:
BIGNUM FIXNUM KEYWORD STANDARD-CHAR STRING-CHAR
(replace STRING-CHAR with BASE-CHARACTER if that proposal passes)
Unlike the first list, I constructed this one randomly out of my head.
It's all the standard "interesting" subtypes of the types that are
already listed in part (a), excluding the simple array subtypes.
(3) The statement "For all objects for which CLASS-OF returns a class
with a proper name, TYPE-OF returns that proper name." is questionable.
For example, part (a) requires that TYPE-OF a single-float must return
SINGLE-FLOAT or a subtype of it, but 88-002R requires that CLASS-OF a
single-float be a class whose proper name is FLOAT, or an implementation
dependent subclass of that class. This proposal will force
implementations to create such subclasses, which should be done on its
own merits, not through the back door. Another example is that for
arrays, TYPE-OF will not be able to return a list that encodes the
element-type and dimensions, unless there are implementation dependent
classes corresponding to every such type specifier. There is a really
baroque way to get around this, which is to define an implementation
dependent subclass of ARRAY that has a non-null name that is not its
proper name; this slips through a loophole in the proposal and allows
TYPE-OF to return any subtype of ARRAY. I claim that loophole is a
bug too.
To fix these bugs, I suggest removing the four paragraphs that contain
the three references to CLASS-OF, and replacing them with:
(d) The type returned by TYPE-OF is always a subtype of the class
returned by CLASS-OF, and is a subtype that the implementation's
SUBTYPEP can recognize.
(e) For objects of metaclass STRUCTURE-CLASS or STANDARD-CLASS,
TYPE-OF returns the proper name of the class returned by CLASS-OF
if it has a proper name, and otherwise returns the class itself.
In particular, for objects created by the "constructor" function
of a structure defined with DEFSTRUCT without a :TYPE option,
TYPE-OF will return the structure name.
(4) I suggest modifying part (c) to exclude SATISFIES, AND, OR,
NOT, and VALUES in addition to MEMBER and T. Of course part (c)
is a very weak restriction, since TYPE-OF is perfectly free to
return a symbol that is DEFTYPEd to one of these type specifiers,
as long as the other requirements are met.
∂17-Mar-89 2153 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 21:53:22 PST
Received: from Semillon.ms by ArpaGateway.ms ; 17 MAR 89 21:50:37 PST
Date: 17 Mar 89 21:50 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 1)
In-reply-to: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>'s
message of Wed, 15 Mar 89 15:57:02 GMT
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
cc: Kent M Pitman <KMP@scrc-stony-brook.arpa>, Masinter.PA@Xerox.COM,
CL-Cleanup@sail.stanford.edu
Message-ID: <890317-215037-3421@Xerox>
I think the issue is the handling of the printer. PRINT, when
*PRINT-ESCAPE* is set. needs to look at the case of the readtable to know
how to print out things so they will read in correctly.
Take symbols with symbol-name "Frob" and "FROB" respectively.
print print
Symbol-name case-sensitive case-insensitive
Frob Frob |Frob|
FROB FROB frob, Frob, or FROB
(depending on *PRINT-CASE*)
I think this is a "cleanup" issue, since it is a minor extension
to the feature of readtables and is upward compatible.
∂17-Mar-89 2223 CL-Cleanup-mailer Re: Issue: TYPE-OF-UNDERCONSTRAINED, v.5
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 22:23:00 PST
Received: from Semillon.ms by ArpaGateway.ms ; 17 MAR 89 22:14:13 PST
Date: 17 Mar 89 22:09 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: TYPE-OF-UNDERCONSTRAINED, v.5
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Sat, 18 Mar 89 00:37 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890317-221413-3463@Xerox>
I think BIT-VECTOR might have been an omission.
NULL was left out because it seemed silly and at odds with current practice
to require that (TYPE-OF 'NIL) = NULL. However, if (CLASS-OF 'NIL) is the
special NULL class, then we would have to reconsider.
SEQUENCE was left out because it is an 'abstract' class and is (as far as
the standard is concerned) exhaustively partitioned by VECTOR and LIST
which are already "lower bounds" of TYPE-OF.
BIGNUM and FIXNUM were left out because their division was implementation
dependent.
KEYWORD was left out because under odd circumstances it is possible to
dynamically change the 'type' (e.g., by UNINTERN).
STANDARD-CHAR and STRING-CHAR were left out for the same reasons they
aren't built-in classes.
- - - - -
I like your proposed fixes to the CLASS-OF wording.
- - - - -
About part (c): the restriction on T is meaningless, since the CLASS-OF
restriction dominates it. The restriction on MEMBER is OK, just to keep
TYPE-OF from being the silly definition that (type-of x) = `(member ,x). I
think we're running out of good reasons to leave out SATISFIES, AND, OR,
NOT, and VALUES; they're probably no more useful, but we're probably
overspecifying for no good reason.
However, I'll be happy to go along with whatever you feel is right on this
one...
∂17-Mar-89 2235 CL-Cleanup-mailer Issue: PRETTY-PRINT-INTERFACE (version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 22:35:17 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560283; Sat 18-Mar-89 01:32:31 EST
Date: Sat, 18 Mar 89 01:32 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PRETTY-PRINT-INTERFACE (version 3)
To: Guy Steele <gls@Think.COM>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8903152049.AA03416@verdi.think.com>
Message-ID: <19890318063223.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
In general I like this. Certainly I like the idea of having a
standardized interface for extending the pretty-printer, and I believe
that this particular pretty-printer is based on a good underlying
theory, certainly the best theory that I have seen. However, I don't
think this is ready to go into the standard in its current form. Some
of these comments are on the programmer interface, others are just on
the way the proposal is presented.
I could not find any specification of the units of measurement for
*PRINT-RIGHT-MARGIN*, *DEFAULT-RIGHT-MARGIN*, *PRINT-MISER-WIDTH*,
indentation, and tabulation. It's not even clear that margins,
indentation, and tabulation can't be measured in three different
units. Analysis of the examples suggests that the units are
assumed to be characters and all characters are assumed to be the
same width. This is not an implementation-independent assumption.
In any case the proposal has to be specific about the units. I
would prefer something that seamlessly accomodates variable-width
characters, but don't have enough experience with pretty-printers
to propose anything myself.
I would like to be able to vote on the FORMAT-based interface and
the functional interface separately.
I would like to see the DEFINE-PRINT-DISPATCH mechanism recast in terms
of DEFMETHOD and a PRETTY-PRINT-OBJECT generic function. If DEFMETHOD
is deficient and unable to provide all the necessary features, I think
we need to know that before it's too late to amend CLOS. I don't see
any problems myself, other than the need to replace the funny extension
to the CONS type-specifier with passing of the CAR of the CONS as a
separate argument so an EQL parameter specializer can be used.
I'd like to suggest some improvements to the syntax of
WITHIN-LOGICAL-BLOCK, based on Symbolics experience with similar macros:
Instead of separate :STREAM and :VAR keywords, it works better to have
only a :STREAM keyword, whose value must be a symbol. This symbol
is evaluated to get the stream, and also is bound around the body to
a (possibly new) stream. This simplifies the syntax and avoids the
risk of accidentally writing to the wrong stream.
Defaulting to *STANDARD-OUTPUT* and handling T and NIL is correct here
(:STREAM NIL means *STANDARD-OUTPUT* is the variable that gets bound.)
Since the :ARG argument appears to be mandatory, it should be a
required argument preceding the keyword arguments. This would also
eliminate the meaningless keyword name for this argument.
It would be nice if the :PREFIX, :PER-LINE-PREFIX, and :SUFFIX
arguments could be functions as well as strings, to allow more control
over the printing of this information. That's not essential, but it
would for example make it easier to print special characters.
The :FROM-START and :FROM-POSITION values for KIND in LOGICAL-BLOCK-INDENT
are too easily confused. I suggest renaming them to :BLOCK and :CURRENT
and renaming the argument to RELATIVE-TO.
The functional interface is missing equivalents for the
~/TABULAR-STYLE/, ~/FILL-STYLE/, and ~/LINEAR-STYLE/ features.
I think it's better to provide these as predefined functions
than to make the user define them himself.
∂17-Mar-89 2254 CL-Cleanup-mailer Re: Issue: LOAD-OBJECTS (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 22:54:01 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560294; Sat 18-Mar-89 01:50:31 EST
Date: Sat, 18 Mar 89 01:50 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: LOAD-OBJECTS (Version 3)
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>, Richard P. Gabriel <rpg@lucid.com>
cc: CL-Cleanup@sail.stanford.edu, CL-Compiler@sail.stanford.edu, Common-Lisp-Object-System@sail.stanford.edu
In-Reply-To: <8903120142.AA00878@defun.utah.edu>
Message-ID: <19890318065022.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
There are a couple of small changes that seem warranted:
MAKE-LOAD-FORM-USING-SLOTS is too easy to confuse with
SLOT-VALUE-USING-CLASS. MAKE-LOAD-FORM-FROM-SLOTS is better,
except for form/from dyslexia. MAKE-LOAD-FORM-FOR-SLOTS ?
Maybe there should be a SIMILAR-AS-CONSTANTS generic function
for the benefit of CONSTANT-COLLAPSING. In the absence of that
we're just using EQ.
On the subject of this proposed alternative:
Date: Sat, 11 Mar 89 18:42:56 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Have two generic functions, not one. The first would get called by
compile-file and it would return a list of components (or whatever)
that are required to reconstruct the object. The compiler would dump
this list of objects in its usual way. The loader would apply the
second generic function to this list to reconstruct the object.
This is exactly the way I did the first implementation of this idea,
back in about 1978. It didn't work very well, basically for two reasons.
One is that representing information in the form of lists is pretty
impoverished and it's very easy to get the list the wrong length or
out of order; it's also more difficult than it should be to make
upward-compatible changes, because the new format always has to be
a superset of the old format. Forms are more general. You can make
upward-compatible changes by inventing a new function name and keeping
the old function name around forever with the old semantics; this also
ensures an undefined-function error if the new format is loaded into
the old system.
The second reason is more serious. The way you propose cannot be nicely
extended to deal with circular structures, because it fails to separate
object creation from object initialization. The second generic function
does both operations. My application used circular structures
extensively and had a fairly horrible kludge for them, involving standin
objects that were replaced with the correct objects later in loading;
this was fragile and permeated the reconstruction methods, all the worst
characteristics for this kind of thing.
On the subject of forms versus functions as the interface, I think
David Gray has expressed very well the reasons why that is not
practical, at least at Common Lisp's present stage of development.
I've read all the mail on the subject, but I stand by LOAD-OBJECTS
version 3. There may be more thought behind this proposal than is
apparent at first glance.
∂17-Mar-89 2300 CL-Cleanup-mailer Re: Issue: TYPE-OF-UNDERCONSTRAINED, v.5
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 23:00:36 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560300; Sat 18-Mar-89 01:57:45 EST
Date: Sat, 18 Mar 89 01:57 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: TYPE-OF-UNDERCONSTRAINED, v.5
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <890317-221413-3463@Xerox>
Message-ID: <19890318065727.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 17 Mar 89 22:09 PST
From: masinter.pa@Xerox.COM
I think BIT-VECTOR might have been an omission.
NULL was left out because it seemed silly and at odds with current practice
to require that (TYPE-OF 'NIL) = NULL. However, if (CLASS-OF 'NIL) is the
special NULL class, then we would have to reconsider.
In Symbolics Genera 7.4, (TYPE-OF 'NIL) => NULL, so that's some current
practice. 88-002R mandates (SUBTYPEP (CLASS-OF 'NIL) (FIND-CLASS 'NULL)).
SEQUENCE was left out because it is an 'abstract' class and is (as far as
the standard is concerned) exhaustively partitioned by VECTOR and LIST
which are already "lower bounds" of TYPE-OF.
It is not an exhaustive partition, according to CLtL p.35. I put
SEQUENCE in so that if an implementation adds a third kind of SEQUENCE,
TYPE-OF can't be any less specific than SEQUENCE. This is the same reason
that RATIONAL, FLOAT, and NUMBER are in.
BIGNUM and FIXNUM were left out because their division was implementation
dependent.
KEYWORD was left out because under odd circumstances it is possible to
dynamically change the 'type' (e.g., by UNINTERN).
STANDARD-CHAR and STRING-CHAR were left out for the same reasons they
aren't built-in classes.
I'll buy the above three paragraphs, although I don't think any of them
are 100% compelling.
∂17-Mar-89 2320 CL-Cleanup-mailer Re: Issue: PLUS-ABNORMAL (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 23:20:10 PST
Received: from Semillon.ms by ArpaGateway.ms ; 17 MAR 89 23:17:01 PST
Date: 17 Mar 89 23:16 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PLUS-ABNORMAL (Version 1)
In-reply-to: masinter.pa's message of 15 Mar 89 07:33 PST
To: CL-Cleanup@SAIL.Stanford.EDU, skona%csilvax@hub.ucsb.edu
Message-ID: <890317-231701-3536@Xerox>
Can we drop this one? Complaints only.
∂17-Mar-89 2357 CL-Cleanup-mailer Re: environment argument for SUBTYPEP
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 23:57:39 PST
Received: from Semillon.ms by ArpaGateway.ms ; 17 MAR 89 23:54:56 PST
Date: 17 Mar 89 23:54 PST
From: masinter.pa@Xerox.COM
Subject: Re: environment argument for SUBTYPEP
In-reply-to: David N Gray <Gray@DSG.csc.ti.com>'s message of Wed, 11 Jan 89
15:57:47 CST
To: David N Gray <Gray@DSG.csc.ti.com>, cl-cleanup@sail.stanford.edu, "Kim
A. Barrett" <IIM@ECLA.USC.EDU>
Message-ID: <890317-235456-3561@Xerox>
Somehow I dropped some mail; I don't have the proposal, although there's a
reference to version 1 of SUBTYPEP-ENVIRONMENT. Is this ready?
∂18-Mar-89 0026 CL-Cleanup-mailer [cl-cleanup@sail.stanford.edu: Issue:
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 18 Mar 89 00:26:17 PST
Received: from Semillon.ms by ArpaGateway.ms ; 18 MAR 89 00:24:02 PST
Date: 18 Mar 89 00:22 PST
From: masinter.pa@Xerox.COM
Subject: [cl-cleanup@sail.stanford.edu: Issue:
UNDEFINED-VARIABLES-AND-FUNCTIONS (Version 1)]
To: rpg@lucid.com, gregor.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
line-fold: NO
Message-ID: <890318-002402-3587@Xerox>
Moon's notes from Jan 89 X3J13:
"Lumping SLOT-UNBOUND in with unbound special variables was a mistake,
as SLOT-UNBOUND is an extension mechanism, not only a safety checking
mechanism. Also there were some wording problems. Gabriel and Gregor
are to submit a revised proposal."
No revised proposal has been submitted.
Now that you know what "safe" is, you can safely do so. Eh?
----- Begin Forwarded Messages -----
Date: 11 Jan 89 23:45 PST
Sender: masinter.pa
Subject: Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS (Version 1)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter
line-fold: No
It was believed that this issue might be controversial.
!
Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS
References: 5.1.2 Variables (CLtL pp55-56),
Slots (88-002R, p1-10)
Category: CHANGE
Edit history: 29-Nov-88, Version 1 by Pitman
Problem Description:
CLtL does not specify what happens if you attempt to call a named function
which is in fact undefined. In most implementations, it would be devastating to
actually jump to code which you had not verified to be a function, so this error
should be easily caught -- yet, CLtL does not guarantee that an error will be
signalled even in the safest, least fast OPTIMIZE settings.
CLtL (p56) specifies that "it is an error to refer to a variable that is unbound."
CLOS (p1-10) specifies that "when an unbound slot is read, the generic function
SLOT-UNBOUND is invoked. The system-supplied primary method for SLOT-UNBOUND
signals an error."
CLOS and CLtL are not in agreement on their treatment of unbound variables.
CLtL is very weak in that it guarantees no support for reliably detecting
and signalling an error when the error situation occurs, even in the safest,
least fast OPTIMIZE setting.
CLOS is very strong in that it forces detection of the error in all
situations -- even in the fastest, least safe OPTIMIZE setting.
The disparate positions for treatment of variables and slots should be
reconciled, either by finding a compromise or by justifying the apparent
inconsistency. The final story should explain function references as well.
Proposal (UNDEFINED-VARIABLES-AND-FUNCTIONS:COMPROMISE):
Define that reading an undefined function, an unbound variable, or
an unbound slot must be detected in the highest safety setting,
but the effect is undefined in any other safety setting. That is,
- Reading an undefined function should signal an error.
- Reading an an unbound variable should signal an error.
- Reading an unbound slot should invoke the function SLOT-UNBOUND.
By ``reading an undefined function'' in the above, we mean to
include both references to the function using the FUNCTION
special form, such as F in (FUNCTION F) and references to the
function in a call, such as F in (F X).
For the case of INLINE functions (in implementations where they are
supported), it is permissible to consider that performing the inlining
constitutes the read, so that an FBOUNDP check need not be done at
execution time. Put another way, the effect of FMAKUNBOUND of a function
on potentially inlined references to that function is undefined.
Specify that the type of error signalled when an undefined function
is detected is UNDEFINED-FUNCTION, and that the NAME slot of the
UNDEFINED-FUNCTION condition is initialized to the name of the
offending function.
Specify that the type of error signalled when a unbound variable
is detected is UNBOUND-VARIABLE, and that the NAME slot of the
UNBOUND-VARIABLE condition is initialized to the name of the
offending variable.
Introduce a new condition type, UNBOUND-SLOT, which inherits from
CELL-ERROR. This new type has an additional slot, INSTANCE, which
can be initialized using the :INSTANCE keyword to MAKE-CONDITION.
Introdue a new function UNBOUND-SLOT-INSTANCE to access INSTANCE slot.
Specify that the type of error signalled by the default primary
method for the SLOT-UNBOUND generic function is UNBOUND-SLOT,
and that the NAME slot of the UNBOUND-SLOT condition is initialized
to the name of the offending variable, and that the INSTANCE slot
of the UNBOUND-SLOT condition is initialized to the offending instance.
Test Case:
(PROCLAIM '(OPTIMIZE (SAFETY 3) (SPEED 0)))
(DEFUN FOO () X)
(FOO)
>>Error: The variable X is not bound.
...
Rationale:
This makes it easier to treat slots like variables.
This makes it possible to better rely on an unbound variable error being
signalled when one has occurred.
This makes it possible to compile out useless error checking in CLOS
code where the code is debugged and the checking is redundant.
For the case of undefined functions, blindly jumping to an undefined
function is an incredibly dangerous thing to do. Every implementation
should guarantee at least some way to get error checking of undefined
functions.
Current Practice:
Until recently, Symbolics Cloe did not ever signal an error on unbound
variable, even in the safest case. The excuse was that this was a CLtL
didn't require it, but it was sometimes an impediment to debugging.
Some benchmarks for Symbolics Cloe (which currently only claims to
implement New Flavors, not CLOS) could be faster if checking for unbound
instance variables could be optimized away.
Symbolics Genera doesn't care about safety issues in variable access
because the check can be done by microcode.
Cost to Implementors:
This change does not force a change to any current implementation, except
those which do not yet signal unbound variable or undefined function errors
even in the safest setting.
Cost to Users:
This checking might slow down some code which is written for the safest
setting yet does not need this check.
Any implementation-specific code which depended on these references not
signalling would be broken. Such code was not portable, of course.
Any CLOS code which depends on SLOT-UNBOUND being called even in low safety
settings would be broken. The amount of such code at this point is likely
to be little or none. If such cases did exist, local or global changes to
safety settings would correct the problem (at some cost in speed).
Cost of Non-Adoption:
Some important error checking would not occur.
Some important optimizations could not be done.
The language would seem internally less consistent.
Benefits:
The costs of non-adoption would be avoided.
Aesthetics:
This would regularize things a little.
Discussion:
Pitman thinks this would be a good idea.
----- End Forwarded Messages -----
∂18-Mar-89 0122 CL-Cleanup-mailer Cleanup Issue Status List
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 18 Mar 89 01:22:13 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 18 MAR 89 01:19:53 PST
Date: 18 Mar 89 01:19 PST
From: masinter.pa@Xerox.COM
to: cl-cleanup@sail.stanford.edu
Subject: Cleanup Issue Status List
Message-ID: <890318-011953-3626@Xerox>
I think this issue status is up to date.
I think I have updated versions of all pending and passed
issues stored on arisia.xerox.com under the
clcleanup/pending
clcleanup/passed
directories respectively.
I'm pretty much unavailable (travelling, etc.)
until the meeting. If there are new versions
of any issues that are ready for release, or any
new issues that are important, please email to X3J13.
I'll try to read my mail while on the road, but
it will be difficult to handle the quantity we've
seen in the last week.
I'll send a short version of this list to X3J13.
Codes:
! released for Jan 89 meeting
+ passed
- withdrawn, failed, tabled indefinitely, etc.
* need new version
!*: released, but I know we'll need a new version
+*: passed, but need to reconsider
!*: passed, but need a new version to reconsider
!
+ ADJUST-ARRAY-DISPLACEMENT
Version 4, 23-Nov-87
Status: passed, 1988
+ ADJUST-ARRAY-FILL-POINTER
Version 1, 15-MAR-88
Status: passed, 1988
! ADJUST-ARRAY-NOT-ADJUSTABLE
Synopsis: ADJUST-ARRAY on array made with :ADJUSTABLE NIL: "an error"?
Version 4, 11-Jan-89, Released 12-Jan-89
Status: Accepted with amendments Jan 89 X3J13
Comments: amendment had wording problem.
Version 8, 11-Mar-89, Released 15-Mar-89
Status: ready for vote
- ALIST-NIL
Version 4, 1-Oct-88
Status: Withdrawn, recommend editorial
- APPEND-ATOM
Synopsis: atom case of APPEND (left out of APPEND-DOTTED)
Version 1, 6-Dec-88, Released 12-Jan-89
Status: withdrawn 18-Jan-89 because APPEND-DOTTED withdrawn
- APPEND-DOTTED
14-JAN-88, Version 5
Status: Passed Nov 88 X3J13, reconsidered & withdrawn Jan 89 X3J13
+ APPLYHOOK-ENVIRONMENT
Synopsis: remove (useless) env argument to applyhook
Version 2, 10-Jan-89, Released 10-Jan-89
Status: Passed Jan-89 X3J13
+ AREF-1D
14-NOV-87, Version 7
Status: Passed, 1988?
+ ARGUMENTS-UNDERSPECIFIED
Synopsis: Clarify various ranges missing from CLtL
Version 4, 21-Sep-88, Released 4 Dec 88
Status: Passed Jan 89 X3J13
+ ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Synopsis: What do array element-type declarations mean?
Version 9, 31-Oct-88, Released 5 Dec 88
Status: Passed Jan 89 X3J13
+ ASSOC-RASSOC-IF-KEY
Version 4, 23-NOV-87
Status: Passed, 1988?
- BACKQUOTE-COMMA-ATSIGN-DOT
Synopsis: `(... ,@x) vs `(... . ,x). Same, different, is error?
Version 1, 22-Dec-88, DRAFT released
Comments: proposals INTERCHANGABLE and DIVERGENT comments not in writeup
Status: Withdrawn, since APPEND-DOTTED withdrawn. Default is IS ERROR
! BREAK-ON-WARNINGS-OBSOLETE
Synopsis: deprecate *BREAK-ON-WARNINGS* because of *BREAK-ON-SIGNALS*
Version 1, 07-Mar-89, Released 15-Mar-89
Comment: leaves out a case
Status: ready for vote
! CLOS-CONDITIONS
Version 4, 10-Mar-89
Comments: define metaclass of conditions?
Status: pending
+ CLOSE-CONSTRUCTED-STREAMS
Synopsis: What does it mean to CLOSE a constructed stream?
Version 2, 12-Jan-89, Released 12-Jan-89
Status: Proposal ARGUMENT-STREAM-ONLY passed Jan 89 X3J13
!+ CLOSED-STREAM-OPERATIONS
Synopsis: What operations are legal on closed streams?
Version 5, 5-Dec-88, released 5-Dec-88
Status: amended at meeting
Version 7, 14-Feb-89
Status: Passed, as amended, Jan 89 X3J13
Comment: amendment bad; reconsider version 5.
say that INPUT-STREAM-P and OUTPUT-STREAM-P
are undefined on closed streams?
! COERCE-INCOMPLETE
Synopsis: Extend COERCE
Version 3, 7-Mar-89, Released 14-Mar-89
Status: ready for voting
+ COLON-NUMBER
Synopsis: :123 is an error
22-OCT-87, Version 1
Status: Passed, 1988?
+ COMPILER-WARNING-STREAM
Version 6, 5-JUN-87
Status: Passed, 1988?
+ COMPLEX-ATAN-BRANCH-CUT
Synopsis: tweak upper branch cut in ATAN formula
Version 1, 13-Dec-88, Released 10-Jan-89
Status: Passed Jan 89 X3J13
!* CONDITION-RESTARTS
Synopsis: can't know whether restart is associated with signalling
Version 1, 18-Jan-89, released 16-Mar-89
Comment: (proposed amendments)
Status: need new version
+ CONTAGION-ON-NUMERICAL-COMPARISONS
Version 1, 14-Sep-88, Released 6 Oct 88
Status: passed, Jan 89 X3J13
! COPY-SYMBOL-COPY-PLIST
Version 1, 10-Jan-89, released 16-Mar-89
Status: ready for vote
! COPY-SYMBOL-PRINT-NAME
Version 2, 15-Mar-89, released 16-Mar-89
Status: ready for vote
+ DATA-TYPES-HIERARCHY-UNDERSPECIFIED
4-SEP-88 Version 2
Status: Passed, 1988?
+ DECLARATION-SCOPE
Version 4, 15-Nov-88, Released 9-Dec-88
Status: NO-HOISTING passed Jan 89 X3J13
+ DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Version 3, 13-Jan-89
Status: passed, Jan 89 X3J13
+ DECLARE-FUNCTION-AMBIGUITY
Version 4, 5-Dec-88, Released 5-Dec-88
Status: passed, Jan 89 X3J13
+ DECLARE-MACROS
5-FEB-88, Version 3
Status: Passed, 1988?
+ DECLARE-TYPE-FREE
Version 10, 12-Jan-89
Status: proposal LEXICAL passed Jan 89 X3J13
- DECLARE-TYPE-USER-DEFINED
Synopsis: allow (declare ((signed-byte 8) x y z)) for all type specifiers?
Status: Withdrawn (never submitted)
+ DECODE-UNIVERSAL-TIME-DAYLIGHT
Version 2, 30-Sep-88, Released 6 Oct 88
Status: Passed, Jan 89 x3j13
- DEFINITION-DELETE
Synopsis: provide a way to get rid of structures, etc.
Status: not submitted
* DEFMACRO-LAMBDA-LIST
Version 2, 17-Mar-89
Status: ready for release?
+ DEFPACKAGE
Version 7, 2-Nov-88, Released 5 Dec 88
Comment: clarify "at variance" in editorial work?
Status: Passed, Jan 89 X3J13
- DEFSTRUCT-ACCESS-FUNCTIONS-INLINE
Synopsis: defstruct accessors are proclaimed inline
Version 2, 7-Jan-89, released 10-Jan-89
Status: rejected, Jan 89 X3J13
+ DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
Version 3, 8-Jan-89, Released 11-Jan-89
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-DEFAULT-VALUE-EVALUATION
Version 1, 5/13/88
Status: Passed, 1988
+ DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
Version 3, 7 Dec 88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-REDEFINITION
Synopsis: what happens if you redefine a DEFSTRUCT?
Version 3, 6-Feb-89
Status: Passed (as amended) Jan 89 X3J13
+ DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
Version 5, 12-Jan-89
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER
Version 1, 5/13/88
Status: Passed, 1988
+ DEFVAR-DOCUMENTATION
23-NOV-87, Version 2
Status: Passed, 1988?
+ DEFVAR-INIT-TIME
29-MAR-87, Version 2
Status: Passed, 1988?
+ DEFVAR-INITIALIZATION
Version 4 5-JUN-87
Status: Passed, 1988?
- DELETE-FILE-NONEXISTENT
Version 1, 5-Oct-88
Comments: should just signal different errors?
Status: withdrawn/tabled?
+ DESCRIBE-INTERACTIVE
Version 4, 15-Nov-88, Released 7-Dec-88
Synopsis: can DESCRIBE ask user a question?
Status: Proposal NO passed Jan 89 X3J13
! DESCRIBE-UNDERSPECIFIED
Version 1, 10-Mar-89, Released 16-Mar-89
Synopsis: making DESCRIBE generic was wrong; fix
status: ready for vote
!* DESTRUCTURING-BIND
Version 2, 25-Jan-89, Released 16-Mar-89
Synopsis: add DESTRUCTURING-BIND macro
Status: might need new version before vote
+ DISASSEMBLE-SIDE-EFFECT
Version 3 1/21/88
Status: Passed, 1988
+ DO-SYMBOLS-DUPLICATES
Version 3 23-NOV-87
Status: Passed, 1988?
+ DOTTED-MACRO-FORMS
Version 3, 15-Nov-88, Released 7-Dec-88
Status: passed, Jan 89 X3J13
+ DRIBBLE-TECHNIQUE
14-FEB-88, Version 2
Status: Passed, 1988?
! DYNAMIC-EXTENT
Version 3, 11-Jan-89, released 16-Mar-89
Comments: still some holes
Status: ready for vote?
- ELIMINATE-FORCED-CONSING
Synopsis: Add :RECYCLE or :MODIFY to some sequence fns,
Version 3, 31-Aug-88
Status: withdrawn
- ENVIRONMENT-ENQUIRY
Synopsis: "The environment inquiry functions (pp447-448) don't return a
value in consistent format across implementations. This makes
them virtually useless. I would like to constrain the values
enough so that implementors knew what to provide as return
values, and provide some examples of intended uses."
Status: no volunteer to submit
+ EQUAL-STRUCTURE
Version 6, 11-Jan-89, Released 12-Jan-89
Status: Passed with amendments
Version 7, 15-Mar-89
Status: Passed Jan 89 X3J13 as amended.
* EQUALP-GENERIC
Version 1, 28-Feb-89
Synopsis: make EQUALP generic function
Comments: Various problems being worked on
Status: ** NEED NEW VERSION ***
* ERROR-CHECKING-IN-NUMBERS-CHAPTER
Version 1, 6-Mar-89
Synopsis: define 'should signal', 'might signal' for number fns
Status: ** NEED NEW VERSION **
! ERROR-NOT-HANDLED
Version 1, 25-Sep-88, Released 6-Oct-88 and 14-Mar-89
Status: ready for vote
+ EVAL-OTHER
8-JUN-88, Version 2
Status: Passed, 1988?
! EXIT-EXTENT
Version 6, 8-Jan-89, distributed at Jan89 X3J13
Rereleased 16-Mar-89
Status: tabled Jan89; ready for vote
+ EXPT-RATIO
Version 3, 31-Oct-88, Released 7 Dec 88
Status: passed, Jan 89 X3J13
- EXPT-ZERO-ZERO
Synopsis: (EXPT 0.0 0.0) should be undefined
Version 1, 27-Feb-89
Status: withdrawn
- FILE-LENGTH-PATHNAME
Synopsis: extend FILE-LENGTH to work on pathnames
Status: not submitted/ withdrawn
- FILE-WRITE-DATE-IF-NOT-EXISTS
Synopsis: What does FILE-WRITE-DATE do if no such file?
Version: no proposal
Status: => ERRORS-IN-FILE-SYSTEM-CHAPTER????
+ FIXNUM-NON-PORTABLE
Version 4, 7-Dec-88, Released 12-Dec-88
Version 6, 17-Mar-89, as amended
Status: Passed, Jan 89 X3J13, as amended
+ FLET-DECLARATIONS
Version 2, 2 FEB 88
Status: Passed, 1988?
+ FLET-IMPLICIT-BLOCK
Version 6 5-JUN-87
Status: Passed, 1988?
- FOLLOW-SYNONYM-STREAM
Comment: lost in STREAM-ACCESS.
Status: Withdrawn?
+ FORMAT-ATSIGN-COLON
Version 4 5-JUN-87
Status: Passed, 1988?
+ FORMAT-COLON-UPARROW-SCOPE
Version 3, 5 FEB 88
Status: Passed, 1988?
+ FORMAT-COMMA-INTERVAL
Version 2, 15-JUN-87
Status: Passed, 1988?
+ FORMAT-E-EXPONENT-SIGN
Version 2, 2 Oct 88, Released 6 Oct 88
Status: Passed, Jan 89 X3J13
+ FORMAT-OP-C
11-JUN-87, Version 5
Status: Passed, 1988?
- FORMAT-NEGATIVE-PARAMETERS
Synopsis: What does FORMAT do when it gets negative numbers for count?
Version: No proposal
Comment: KMP will incorporate in the list-of-signals part of the signal
proposal?
Status: not submitted
* FORMAT-PLURALS
Synopsis: remove ~P, add ~:@[singular~;plural~]
Status: no proposal
+ FORMAT-PRETTY-PRINT
Version 7, 15 Dec 88, Released 7 Dec 88
Comments: passed, Jan 89 X3j13
- FORMAT-ROUNDING
Synopsis: specify that ~F rounds up
Version 1, 5-Oct-88
Status: withdrawn
- FUNCTION-ARGUMENT-LIST
Synopsis: want way to get argument list
Status: not submitted
+ FUNCTION-CALL-EVALUATION-ORDER
Version 1, 22-MAR-88
Status: Passed, 1988
! FUNCTION-COERCE-TIME
Synopsis: When does SYMBOL-FUNCTION happen in MAPCAR?
Version 2, 16-sep-88, Released 8-Oct-88
Re-released: 16-Mar-89
Status: ready for vote?
+ FUNCTION-COMPOSITION
Synopsis: Add new functions
Version 5, 10-Feb-89
Status: Passed (as amended) Jan 89 X3J13
maybe this was passed as amendment to TEST-NOT-IF-NOT instead
+ FUNCTION-DEFINITION
Version 3, 10-Feb-89
Status: Passed (as amended) Jan 89 X3J13
! FUNCTION-NAME
Comment: renaming of SETF-FUNCTION-VS-MACRO, SETF-PLACES
SETF-FUNCTION-VS-MACRO
Version 3, 4-Nov-87, Released Nov 87
SETF-PLACES
Version 1, 11-Nov-88, Released 9-Dec-88
FUNCTION-NAME
Version 1, 27-Jan-89, Released 16-Mar-89
Status: ready for vote
+ FUNCTION-TYPE
Version 12, 4-SEP-88
Status: Passed, June 1988 X3J13, as amended
+ FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
Synopsis: Change semantics of argument types in function declarations
Version 3, 7-Dec-88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13
+ FUNCTION-TYPE-KEY-NAME
Version 3, 13-FEB-88
Status: Passed, 1988
+ FUNCTION-TYPE-REST-LIST-ELEMENT
Version 5, 14-Nov-88, Released 8-Dec-88
Status: Passed, Jan 89 X3J13
- GCD-NO-ARGUMENTS
Synopsis: make (GCD) undefined
Status: not submitted
! GENSYM-NAME-STICKINESS
Synopsis: no side effects if optional arg supplied
Version 1, 14-Feb-89, Released 14-Mar-89
Status: comments
Version 2, 16-Mar-89
Status: ready for release?
- GET-MACRO-CHARACTER-DISPATCHING
Synopsis: What does GET-MACRO-CHARACTER return for dispatching macros?
Status: not submitted
+ GET-MACRO-CHARACTER-READTABLE
Version 3, 11-Feb-89
Status: Passed (as amended) Jan 89 X3J13
+ GET-SETF-METHOD-ENVIRONMENT
Version 5 13-JUL-87
Status: Passed, 1988?
! HASH-TABLE-ACCESS
Synopsis: Add new accessors for hash-table properties
Version 1, 13-Sep-88 released 8-Oct-88
Version 2, 13 Oct 88, released 16-Mar-89
status: vote
- HASH-TABLE-GC
Synopsis: allow hash tables with GCable keys
Status: no proposal
+ HASH-TABLE-PACKAGE-GENERATORS
Version 7, 8-Dec-88, Released 9-Dec-88
Comments: The test-package-iterator example has the values
from the generator in the wrong order.
Status: passed, Jan 89 X3J13
* HASH-TABLE-PRINTED-REPRESENTATION
Version 2, 8-Jun-88
Comments: Use #S(ARRAY ...), #S(HASH-TABLE...), #S(PATHNAME...)?
Status: need new proposal
- HASH-TABLE-STABILITY
Version 1, 11-Nov-88, Released 12 Dec 88
Comments: superceded HASH-TABLE-KEY-MODIFICATION
Status: Rejected Jan 89 X3J13
+ HASH-TABLE-TESTS
Version 2, 8-Dec-88, Released 8 Dec 8 8
Status: passed Jan 89 X3J13
+ IEEE-ATAN-BRANCH-CUT
Version 2, 11-Jan-89, Released 11-Jan-89
Status: passed, Jan 89 X3J13
* IGNORE-VARIABLE
Synopsis: default (IGNORE IGNORE)
Version 1, 6-Feb-89
+ IMPORT-SETF-SYMBOL-PACKAGE
Version 5 ??-MAY-87
Status: Passed, 1988?
! IN-PACKAGE-FUNCTIONALITY
Version 4, 12-Dec-88, Released 12-Dec-88
Status: tabled
Version 8, 15-Mar-89, Released 15-Mar-89
Status: ready for vote
- IN-SYNTAX
Synopsis: like IN-PACKAGE but for readtables
Version 1, 21-Oct-88
Comments: important issue: default environment for LOAD
Status: can we withdraw?
- INPUT-STREAM-P-CLOSED
Synopsis: What do INPUT-STREAM-P and OUTPUT-STREAM-P do on closed streams?
Status: not submitted
- INPUT-STREAM-P-EXAMPLE
Synopsis: (input-stream-p (make-broadcast-stream)) is NIL
Version 1, 26-Oct-88
Status: bug report, needs no clarification?
+ KEYWORD-ARGUMENT-NAME-PACKAGE
8-NOV-87, Version 8
Status: Passed, 1988?
- LAMBDA-FORM
Version 4, 22-Nov-88, Released 8-Dec-88
Status: rejected, Jan 89 X3J13
+ LAST-N
12-MAR-88, Version 2
Status: Passed, 1988?
+ LCM-NO-ARGUMENTS
Version 1, 17 Oct 88, Released 8 Dec 88
Status: passed, Jan 89 X3J13
- LEAST-POSITIVE-SINGLE-FLOAT-NORMALIZATION
Synopsis: should LEAST-POSITIVE- and MOST-POSITIVE-XXX-FLOAT
numbers include denormalized ones in those implementations
that admit them?
Status: Not submitted
! LISP-PACKAGE-NAME
Synopsis: change LISP to COMMON-LISP to avoid CLtL confusion
Version 1, 22 Dec 88, Released 11-Jan-89
Status: tabled; version 1 still ready for vote
! LISP-SYMBOL-REDEFINITION
Version 5, 22-Nov-88, Released 8 Dec 88
Comments: Don't like (DEFVAR CAR ...) example
14: Like simpler "Redefining any documented
definition on a symbol in the LISP package -- such as variables,
functions, constants, properties and property-lists, etc -- is
undefined, except for the explicitly allowed cases (e.g. dynamic
binding of variables)."
Status: tabled; version 5 still ready for vote
- LIST-TYPE-SPECIFIER
Synopsis: add a type specifier (LIST NUMBER)
Version 1, 28 Jun 88
Status: withdrawn
! LOAD-OBJECTS
Synopsis: Provide a way to allow defstruct/defclass objects in compiled files
Version 3, 9-Mar-89, released 16-Mar-89
Status: ready for vote?
! LOAD-TRUENAME
Synopsis: Make default pathname for LOAD inside LOAD same?
Version 1, 13-Mar-89, Released 16-Mar-89
Status: ready for vote
! LOCALLY-TOP-LEVEL
Version 2, 16-Mar-89, released 17-Mar-89
Status: ready to vote
! LOOP-AND-DISCREPANCY
Version 1, 15-Mar-89, released 16-Mar-89
status: ready for vote
+ MACRO-FUNCTION-ENVIRONMENT
Version 2, 8-JUN-88
Status: Passed, 1988
* MACRO-SPECIAL-FORMS
Synopsis: macros => implementation-dependent special forms doesn't work
Status: *** NEED PROPOSAL SUBMITTED ****
- MAKE-CONCATENATED-STREAM-EXAMPLE
Synopsis: (read (make-concatenated-stream (make-string-input-stream "1")
(make-string-input-stream "2"))) => 12?
Version 1, 26-Oct-88
Status: withdrawn, no issue (bug report to one implementation)
+ MAKE-PACKAGE-USE-DEFAULT
Version 2, 8 Oct 88, Released 12-Dec-88
Version 3, 16-Mar-89
Status: Passed, Jan 89 X3J13 as amended
! MAKE-STRING-FILL-POINTER
Synopsis: extend MAKE-STRING to take a fill-pointer?
Version 1, 20-Oct-88, released 16-Mar-89
Status: ready for vote
+ MAPPING-DESTRUCTIVE-INTERACTION
Version 2, 09-Jun-88, Released 8 Oct 88
Synopsis: [don't] define interaction of DELETE on MAPCAR'd list.
Status: passed, Jan 89 X3J13
+ NTH-VALUE
Version 4, 8-Dec-88, Released 8 Dec 88
Comment: amended to clarify when index out of range
Version 5, 17-Mar-89
Status: passed, as amended
- OUTPUT-STREAM-P-EXAMPLE
Synopsis: Clarify (output-stream-p (make-concatenated-stream)) is NIL?
Version 1, 26-Oct-88
Comment: already clear; just bug report for one implementation
+ PACKAGE-CLUTTER
Version 6, 12-Dec-88, Released 12-Dec-88
Comments: Accepted, with amendment
Version 7, 17-Mar-89
Status: Passed, Jan 89 X3J13, as amended
+ PACKAGE-DELETION
Version 5, 21 nov 88, Released 8 Dec 88
Comments: Minor glitches? Remove the description of "correctable" error to be signalled and
handled.
Status: passed, Jan 89 X3J13
!+ PACKAGE-FUNCTION-CONSISTENCY
Synopsis: allow strings for package arg everywhere uniformly
Version 2, 12-Jan-89, Released 12-Jan-89
Comment: Accepted MORE-PERMISSIVE with amendments
Version 3, 17-Mar-89, released 17-Mar-89
Status: vote to accept wording as intent of amendment
* PATHNAME-CANONICAL-TYPE
Synopsis: allow canonical :SOURCE-LISP to MAKE-PATHNAME;
require PATHNAME-TYPE to return same?
Version 1, 07-Jul-88
Comments: only add the :TYPE :SOURCE-LISP, not PATHNAME-CANONICAL-TYPE?
Status: => "pathname" committee?
- PATHNAME-COMPONENT-CASE
Synopsis: allow ALL UPPER CASE to mean "use the 'right' case
Comments: lots of heat?
Status: withdraw?
- PATHNAME-EXTENSIONS
Synopsis: allow a way of telling whether a pathname is a pattern, a "funny"
file
Comments: necessary in standard?
Status: => "pathname" committee
* PATHNAME-LOGICAL
Synopsis: add logical pathnames (pathnames for an imaginary portable
file system, which get translated by site-dependent translations into
physical pathnames on an actual file system)
Status: no proposal yet
* PATHNAME-PRINT-READ
Synopsis: Print pathnames like #P"asdf"?
Version 1, 21-Oct-88
Comments: Numerous, pro, con. Print like #S(pathname ...)?
Status: *** NEED NEW VERSION ***
+ PATHNAME-STREAM
Version 6 14-NOV-87
Status: Passed, 1988?
+ PATHNAME-SYMBOL
Version 5 5-FEB-88
Status: Passed, 1988?
* PATHNAME-SUBDIRECTORY-LIST
Synopsis: How to deal with subdirectory structures in pathname functions
Version 3, 29-Dec-88
Comments: typos and proposed simplifications
Status: *** NEED NEW VERSION ***
* PATHNAME-SYNTAX-ERROR-TIME
Synopsis: when are errors in pathnames detected?
Version 1, 7-Jul-88
Comments: various
Status: need new version? ==> ERRORS-IN-FILE-CHAPTERS?
- PATHNAME-TYPE-UNSPECIFIC
Version 1 27-Jun-88, Released 7 Oct 88
Comments: may be subsumed
Status: withdrawn; superceded by PATHNAME-UNSPECIFIC-COMPONENT
+ PATHNAME-UNSPECIFIC-COMPONENT
Synopsis: More extensions to :UNSPECIFIC
Version 1, 29-Dec-88, Released 12-Jan-89
Version 2, 17-Mar-89
Status: Passed, Jan 89 X3j13, as amended
- PATHNAME-WILD
Version 2, 6-Oct-88
Synopsis: Portable way to ask about "wildcard" pathnames?
Comments: consistent with PATHNAME-COMPONENT-CASE?
Status: => "pathname" committee
+ PEEK-CHAR-READ-CHAR-ECHO
Version 3, 8-Oct-88, Released 8 Oct 88
Synopsis: PEEK-CHAR, READ-CHAR on streams made by MAKE-ECHO-STREAM
Status: Passed, Jan 89 X3J13
- PLUS-ABNORMAL
Version 1, 1-Mar-89
Synopsis: say what happens to + when evaluation aborts
Status: withdraw?
* PRETTY-PRINT-INTERFACE
Version 3, 15-Mar-89
Synopsis: standardize interface to prettyprinter
Status: Need new version
+ PRINC-CHARACTER
29-APR-87, Version 2
Status: Passed, 1988?
* PRINT-CIRCLE-SHARED
Synopsis: does *PRINT-CIRCLE* cause shared structure to print with #=?
Status: Not submitted yet ** NEED WRITEUP **
+ PRINT-CIRCLE-STRUCTURE
Version 3, 20 Sep 88, Released 8 Oct 88
Comments: Accepted, with amendment
Version 4, 17-Mar-89
Status: Passed, Jan 89 X3J13, as amended
! PROCLAIM-LEXICAL
Version 9, 8-Dec-88, Released 12-Dec-88
Synopsis: add LEXICAL proclaimation
Comments: lengthy mail; amendments at Jan meeting
Status: tabled, vote on version 9 (w/o amendments)
+ PUSH-EVALUATION-ORDER
Version 5, 25-NOV-87
Status: Passed, 1988?
+ RANGE-OF-COUNT-KEYWORDS
Version 3, 9-Oct-88, Released 14-Oct-88
Status: passed, Jan 89 X3J13
+ RANGE-OF-START-AND-END-PARAMETERS
Version 1, 14-Sep-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
* READ-CASE-SENSITIVITY
Synopsis: Allow readtables to be case sensitive
Comments: use function or keyword?
Status: need new version
* READ-DELIMITED-LIST-EOF
Synopsis: eof in read deliminted list signals an error
Status: awaiting submission
! REAL-NUMBER-TYPE
Synopsis: add REAL = (OR RATIONAL FLOAT) & range
Version 3, 13-Jan-89, released 16-Mar-89
Status: vote?
+ REDUCE-ARGUMENT-EXTRACTION
Version 3 13-FEB-88
Status: Passed, 1988?
!* REMF-DESTRUCTION-UNSPECIFIED
Synopsis: Specification of side-effect behavior in CL
Version 4, 29-Nov-88, Released 12-Jan-89
Status: straw vote in favor of this, BarMar will make amendments
Version 5, 15-Mar-89
Comment: needs a little work
Status: *** NEARLY READY -- NEED NEW VERSION ****
- REMF-MULTIPLE
Synopsis: What does REMF do if it sees more than one INDICATOR?
Version 2, 12-Jan-89, Released 12-Jan-89
Status: withdrawn ("only applies in 'cannot happen' situation")
+ REQUIRE-PATHNAME-DEFAULTS
Version 6, 9 Dec 88, Released 09 Dec 88
Status: passed, Jan 89 X3j13
+ REST-LIST-ALLOCATION
Version 3, 12-Dec-88, Released 12-Dec-88
Status: proposal MAY-SHARE passed, Jan 89 X3J13
- REST-LIST-EXTENT
Synopsis: allow way to declare dynamic extent &REST
Comment: superseded by DYNAMIC-EXTENT
Status: withdrawn
+ RETURN-VALUES-UNSPECIFIED
Version 6, 9 Dec 88, Released 9-Dec-88
Status: passed, Jan 89 X3J13
+ ROOM-DEFAULT-ARGUMENT
Version 1, 12-Sep-88, Released 8 Oct 88
Status: passed, Jan 89 X3J13
- SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
Version 6, 06-Oct-88, Released 11-Jan-89
Comments: New version scales down previously rejected version
Status: Version 6 rejected Jan 89 X3J13
* SETF-MULTIPLE-STORE-VARIABLES
Synopsis: Allow multiple "places" in SETF stores
Version 1, 5-Dec-88
Status: *** NEED NEW VERSION ****
+ SETF-SUB-METHODS
Version 5, 12-Feb-88, Released 8 Oct 88
Synopsis: careful definition of order inside (SETF (GETF ...) ...)
Status: passed, Jan 89 X3J13
+ SHADOW-ALREADY-PRESENT
Version 4 10-NOV-87
Status: Passed, 1988?
+ SHARPSIGN-PLUS-MINUS-PACKAGE
Version 3 14-NOV-87
Status: Passed, 1988?
- SINGLE-FLOAT-NON-PORTABLE
Synopsis: remove SINGLE-FLOAT, DOUBLE-FLOAT a la FIXNUM?
Status: Not submitted
+ SPECIAL-TYPE-SHADOWING
Synopsis: intersection of types when proclaimed special has local type
declaration
Version 1, 4-Nov-88, released 11-Jan-89
Status: passed, Jan 89 X3J13
- SPECIAL-VARIABLE-TEST
Synopsis: Add SPECIAL-VARIABLE-P?
Version 2, 31-May-88
Status: withdrawn (subsumed by SYNTACTIC-ENVIRONMENT-ACCESS)
+ STANDARD-INPUT-INITIAL-BINDING
Version 8, 8 Jul 88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
- STANDARD-VALUE
Synopsis: user can say binding is "temporary"
Version 1, 21-Oct-88
Comments: not worth trying to standardize now?
Status: withdrawn
+ STEP-ENVIRONMENT
Version 3, 20-Jun-88, Released 7 Oct 88
Version 4, 17-Mar-89
status: Passed, Jan 89 X3J13, as amended
+ STREAM-ACCESS
Version 2, 30-Nov-88, Released 9 Dec 88
Status: ADD-TYPES-ACCESSORS passed, Jan 89 X3J13
- STREAM-CAPABILITIES
Version 1, 7/5/88
Synopsis: SAME-SOURCE-P, SAME-DESTINATION-P, etc
Status: => pathname/file bucket. Withdraw?
- STREAM-DEFINITION-BY-USER
Synopsis: Want user-definable stream types.
Status: not submitted => CL-Windows
- STREAM-ELEMENT-TYPE-EXAMPLES
Version 1, 26-Oct-88
Synopsis: clarify STREAM-ELEMENT-TYPE may return different values?
Status: => editorial
- STREAM-INFO
Version 6, 30-Nov-88, Released 9 dec 88
Status: Rejected, Jan 89 X3J13
+ SUBSEQ-OUT-OF-BOUNDS
29-MAR-88 Version 2
Status: Passed, 1988?
- SUBTYPEP-EMPTY-NIL
Version 1, March 89
Status: => editorial, no cleanup needed
* SUBTYPEP-ENVIRONMENT
Version 1, 2-Jan-89
Status: ** missing writeup ***
+ SUBTYPEP-TOO-VAGUE
Version 4, 7-Oct-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
- SYMBOL-MACROFLET
Version 1, 30 Sep 88
Synopsis: Add SYMBOL-MACROFLET gives lexical function expansion
Status: withdraw? Please?
+ SYMBOL-MACROLET-DECLARE
Version 2, 9-Dec-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13
!+ SYMBOL-MACROLET-SEMANTICS
Version 5, 30-Nov-88, Released 9 Dec 88
Status: Passed, Jan 89 X3J13
Version 6, 14-Mar-89, released 16-Mar-89
Status: ready for vote
- TAGBODY-CONTENTS
Version 5, 9-Dec-88, Released 9 Dec 88
Comments: "good that this failed, but we still need a clarification"
Status: Failed, Jan 89 X3J13
+ TAILP-NIL
Version 5, 9-Dec-88, Released 12-Dec-88
Synopsis: Operation of TAILP given NIL
Status: passed, Jan 89 X3J13
+ TEST-NOT-IF-NOT
Version 3, 1 Dec 88, Released 9 dec
Version 4, 18-Mar-89
Status: Need new version as amended.
! THE-AMBIGUITY
Version 2, 11-Jan-89, Released 11-Jan-89
Comments: typo, sense wrong
Status: tabled, vote on 2
! TIME-ZONE-NON-INTEGER
Version 1, 13-Mar-89, Released 16-Mar-89
Status: ready for vote
- TRACE-ERROR
Synopsis: TRACE should signal errors if it doesn't understand
Version 1, 20-Jun-88
Comments: is this a cleanup?
Status: withdrawn
- TRACE-FUNCTION-ONLY
Synopsis: extend TRACE to handle other specs
Comment: we don't like it
Status: withdrawn
- TRUENAME-SYNTAX-ONLY
Version 1, 12-Sep-88
Synopsis: when does TRUENAME perform checking?
Comments: other options? leave more vague? Other questions?
Status: => "pathname"?
+* TYPE-OF-UNDERCONSTRAINED
Version 3, 12-Dec-88, Released 12 Dec 88
Comments: Accepted, with amendments
Version 5, 16-Mar-89
Comments: constraints wrong
Status: ** NEED NEW VERSION ***
- TYPE-SPECIFIER-PREDICATE
Synopsis: "Add a new function TYPE-SPECIFIER-P that is true of valid type
specifiers and false of all other Lisp objects. Note that the use of
DEFSTRUCT and DEFTYPE can change the behavior of TYPE-SPECIFIER-P over
time."
Comments: considerable discussion on common lisp mailing list.
Status: probably not
! UNDEFINED-VARIABLES-AND-FUNCTIONS
Synopsis: What happens on an undefined function call, unbound variable ref?
Version 1, 29-Nov-88, Released 11-Jan-89
Comments: Lumping SLOT-UNBOUND in with unbound special variables was a mistake,
as SLOT-UNBOUND is an extension mechanism, not only a safety checking
mechanism. Also there were some wording problems. Gabriel and Gregor
are to submit a revised proposal.
No version arrived.
Status: vote on 1?
+ UNREAD-CHAR-AFTER-PEEK-CHAR
Version 2, 2-Dec-88, Released 12-Dec-88
Status: passed, Jan 89 X3J13
+ VARIABLE-LIST-ASYMMETRY
Version 3, 08-Oct-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13
+ WITH-OUTPUT-TO-STRING-APPEND-STYLE
Version 5, 7-JUN-88
Status: Passed, 1988?
∂18-Mar-89 0216 CL-Cleanup-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 18 Mar 89 02:16:20 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Fri, 17 Mar 89 15:14:23 EST
Date: Fri, 17 Mar 89 15:14 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: masinter.pa@xerox.com, kmp@symbolics.com, cl-cleanup@sail.stanford.edu
In-Reply-To: <19890317000217.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <19890317201410.8.BARMAR@OCCAM.THINK.COM>
Date: Thu, 16 Mar 89 19:02 EST
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Date: Thu, 16 Mar 89 17:22 EST
From: Barry Margolin <barmar@Think.COM>
I would support a version that makes NSUBSTITUTE* be explicitly
specific. I see no reason not to require it to use SETF of CAR or AREF,
as appropriate. Unless someone is working on CAR-coding, I don't think
it precludes any known optimizations.
I'd support that too. In other words, describe NSUBSTITUTE with language
similar to the description of NSUBST.
OK, here goes:
Issue: REMF-DESTRUCTION-UNSPECIFIED
References: (SETF (GET ...) ...), REMPROP, (SETF (GETF ...) ...),
REMF (pp165-167); NREVERSE (p248); DELETE, DELETE-IF,
DELETE-DUPLICATES, NSUBSTITUTE, NSUBSTITUTE-IF (pp254-256);
NCONC, NRECONC (p269); NUNION, NINTERSECTION,
NSET-EXCLUSIVE-OR (pp276-279).
Category: CLARIFICATION/CHANGE
Edit history: 11-Feb-87, Version 1 by Dave Andre (DLA@Symbolics.COM)
29-Oct-87, Version 2 by Pitman (flesh out proposals)
28-Nov-88, Version 3 by Pitman (revised presentation)
29-Nov-88, Version 4 by Pitman (slight editing per DLA)
15-Mar-89, Version 5 by Margolin (amendments discussed in
Hawaii, removed -NOT functions)
17-Mar-89, Version 6 by Margolin (make NSUBSTITUTE* less vague)
Status: For Internal Discussion
Problem Description:
Currently, the exact nature of the side-effect performed by list
modification routines is not specified.
Either the specific modifications allowed should be specified so that
programmers can rely on them and implementors can avoid accidentally
causing problems by introducing well-meaning optimizations, or else
the documentation should explicitly state that the effects are
unspecified so that programmers will not depend on them and
implementors will feel comfortable about doing interesting optimizations.
Proposal (REMF-DESTRUCTION-UNSPECIFIED:EXPLICITLY-VAGUE-EXCEPT-NCONC-AND-NSUBSTITUTE):
[This proposal name is getting way out of hand!]
Clarify that the way in which the destructive behavior of the
operators below is achieved is explicitly vague in a number of ways,
in order to provide individual implementations the necessary
flexibility to do useful optimizations.
(SETF (GETF place indicator) value)
is permitted to either SETF place or to SETF any part, CAR or
CDR, of the top-level list structure held by that place.
(REMF place indicator)
is permitted to either SETF place or to SETF any part, CAR or
CDR, of the top-level list structure held by that place.
(SETF (GET symbol indicator) value)
is constrained to behave exactly the same as
(SETF (GETF (SYMBOL-PLIST symbol) indicator) value).
(REMPROP symbol indicator)
is constrained to behave exactly the same as
(REMF (SYMBOL-PLIST symbol) indicator).
(NREVERSE sequence)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure in that sequence.
when sequence is an array is permitted to re-order the elements
of the given sequence in order to produce the resulting array.
(DELETE object sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure held in that sequence.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(DELETE-IF test sequence ...)
is constrained to behave exactly like
(DELETE NIL sequence
:TEST #'(LAMBDA (IGNORE ITEM) (FUNCALL test ITEM))
...).
(DELETE-DUPLICATES sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure held in that sequence.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(NRECONC list tail)
is constrained to have side-effect behavior equivalent to:
(NCONC (NREVERSE list) tail).
(NUNION list1 list2 ...)
(NINTERSECTION list1 list2 ...)
(NSET-EXCLUSIVE-OR list1 list2 ...)
is permitted to SETF any part, CAR or CDR, of the top-level of
any of the given lists.
Note, however, that since this side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
(NCONC . lists)
is defined using the following recursive relationship:
(NCONC) => NIL
(NCONC NIL . args) == (NCONC . args)
(NCONC arg) => arg
(NCONC arg1 arg2) has the side effect of (RPLACD (LAST arg1) arg2),
and returns arg1
(NCONC arg1 arg2 . args) == (NCONC (NCONC arg1 arg2) . args)
[If a previous cleanup issue prohibited NIL as a non-last argument
then ignore the (NCONC NIL . args) case.]
(NSUBSTITUTE new-object old-object sequence ...)
(NSUBSTITUTE-IF new-object test sequence ...)
is required to SETF any CAR (if SEQUENCE is a list) or VREF (if it's
a vector) of SEQUENCE which is required to be replaced with
NEW-OBJECT. If SEQUENCE is a list, it none of the CDRs of the
top-level list may be modified. These functions, therefore, may be
used in for-effect-only positions in code (some may find this
stylistically distasteful, though).
Note: The above clarifications are not intended as complete functional
descriptions. They are intended to augment (rather than to replace)
other descriptions already in effect.
Test Cases:
For GETF...
(SETQ FOO (LIST 'A 'B 'C 'D 'E 'F)) ==> (A B C D E F)
(SETQ BAR (CDDR FOO)) ==> (C D E F)
(REMF FOO 'C)
BAR ==> ??
In Symbolics Common Lisp, BAR holds (C D E F).
CLtL allows other interpretations. eg, BAR might hold
(C), (NIL), (C NIL) or (C D).
Under this proposal, any of these interpretations (and others as well)
would still be valid
For DELETE...
(SETQ FOO (LIST 'A 'B 'C)) ==> (A B C)
(SETQ BAR (CDR FOO)) ==> (B C)
(SETQ FOO (DELETE 'B FOO)) ==> (A C)
BAR ==> ??
(EQ (CDR FOO) (CAR BAR)) ==> ??
In Symbolics Common Lisp, these last two expressions return ((C)) and T.
Under this proposal, either of these interpretations (and others
as well) would be valid.
For NCONC...
(SETQ FOO (LIST 'A 'B 'C 'D 'E)
BAR (LIST 'F 'G 'H 'I 'J)
BAZ (LIST 'K 'L 'M)) => (K L M)
(SETQ FOO (NCONC FOO BAR BAZ)) => (A B C D E F G H I J K L M)
FOO => (A B C D E F G H I J K L M)
BAR => (F G H I J K L M)
BAZ => (K L M)
(SETQ FOO (LIST 'A 'B 'C 'D 'E)
BAR (LIST 'F 'G 'H 'I 'J)
BAZ (LIST 'K 'L 'M)) => (K L M)
(SETQ FOO (NCONC NIL FOO BAR NIL BAZ)) => (A B C D E F G H I J K L M)
FOO => (A B C D E F G H I J K L M)
BAR => (F G H I J K L M)
BAZ => (K L M)
Rationale:
Implementations already vary widely on their implementation techniques
for these functions. This effectively clarifies the status quo, making
it more clear to programmers what they may rely upon in portable code.
In the case of NCONC, however, the precise definition is useful because
it is what users expect, it is how NCONC has been defined for many
years, and it is how current implementations generally work. It may
not always be the most efficient way (e.g. it may result in invisible
pointers in CDR-coded implementations), but callers of NCONC probably
use it specifically for its precise side effects.
In the case of NSUBSTITUTE, this seems like the only reasonable
implementation mechanism, and there doesn't seem to be a reason not to
guarantee it.
Current Practice:
All valid implementations are believed to comply with the vague
definitions. Symbolics Genera 7.2 and Sun Common Lisp 2.1.3 appear to
conform to the NCONC spec.
Cost to Implementors:
None. This is probably the status quo for most implementors. If there
are any implementations that don't implement NCONC and NSUBSTITUTE as
above (which I doubt) they will have to be changed.
Cost to Users:
This change would not affect programs coded with "good programming
practice". That is, only programs which rely on currently undocumented
features would be in any danger of breaking. In fact, those programs
are already in such danger, and this change to the documentation would
just publicize it. The clarification would -encourage- good programming
practice by warning people to only obey the published contract of the
above-mentioned functions.
There is, however, no automatic technique for making this check for
programs already in error. Bugs due to unexpected side-effects are in
general among the hardest to reckon with.
Cost of Non-Adoption:
Programmers may naively believe there is only one possible or reasonable
implementation of these functions. Some implementors may shy away from
reasonable optimizations out of a paranoid belief that deviating from
some vague, unspoken rules will lead to programmer unrest. Making these
things explicitly vague clarifies the implementor's rights in a way that
permits numerous useful optimizations.
Benefits:
Users would be discouraged from taking advantage of subtle details
of these destructive operations because such details would be explicitly
not guaranteed to be portable.
Implementations can improve performance of many of the above-mentioned
functions when they are not under the constraint to implement them
in a highly constrained fashion. For example, in Symbolics systems,
DELETE of a cdr-coded list could use the implementation primitive
%CHANGE-LIST-TO-CONS rather than RPLACD to avoid creating forwarding
pointers.
Garbage collection effectiveness can also be improved. For example,
all of the destructive operations which remove objects (eg, REMF)
could remove CAR pointers to removed objects which are more volatile
than the list itself, assisting the garbage collector and thereby
improving memory usage and paging performance.
Tightening the definition of NCONC and NSUBSTITUTE permits users to
predict their programs' behavior more precisely.
Non-Benefits:
Users who inadvertently depend on side-effect behavior may be rudely
surprised when moving between implementations.
Compatibility with older Lisp dialects is diminished.
Implementors have less flexibility in implementing NCONC efficiently.
This is true of NSUBSTITUTE, but this is less likely to cause problems.
Performance Impact:
Metering in Symbolics test systems have shown that there are substantial
performance gains to be had by allowing implementations flexibility in
these areas.
In the case of NCONC, this implementation flexibility, and hence
potential performance improvements, is sacrificed.
If anyone ever invents CAR-coding, the required implementation of
NSUBSTITUTE could be a performance hindrance.
Aesthetics:
Most of these functions implement abstract operations. For example,
REMPROP implements an abstract operation on a "property list".
Proper language design should not encourage people to delve below the
level of abstraction into the nitty gritty.
NCONC is a "less abstract" function than the rest of the functions
described above. It is usually used precisely because of the way it
interacts with list implementation. Similarly for NSUBSTITUTE.
Discussion:
Andre's original version of this proposal pushed for explicitly vague
descriptions of these functions' side-effect behavior. He believes
that if users want more predictability from these functions, they
should write private variants that implement whatever predictability
they require.
Pitman originally opposed this position because he weighed portability
a higher concern. Since the original discussion, however, his views on
how to resolve this priority have been refined, and he now believes
that leaving things vague is appropriate. As such, he now supports what
is effectively Andre's original proposal.
Pitman and Andre supported version 4. [I don't know how they feel
about v6 -- Barmar].
Moon supports version 6.
∂18-Mar-89 1708 CL-Cleanup-mailer *DRAFT* Issue: DESTRUCTURING-BIND, v.2
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 18 Mar 89 17:08:07 PST
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88);
Sat, 18 Mar 89 19:07:01 CST id AA09942 for cl-cleanup@sail.stanford.edu
Posted-Date: Sat, 18 Mar 89 19:05:07 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
id AA20299; Sat, 18 Mar 89 19:05:07 CST
Date: Sat, 18 Mar 89 19:05:07 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8903190105.AA20299@pavo.src.honeywell.com>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 16 Mar 89 11:46 PST <890316-114911-4982@Xerox>
Subject: *DRAFT* Issue: DESTRUCTURING-BIND, v.2
If the result of evaluating the expression does not match the
destructuring pattern, the consequences are undefined. Implementations
are not required to signal an error in this case, but neither are they
permitted to extend the behavior by defining it to be harmless.
At the risk of getting rpg started again, what does it mean?
∂18-Mar-89 1720 CL-Cleanup-mailer Issue DESCRIBE-UNDERSPECIFIED, v.1
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 18 Mar 89 17:20:52 PST
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88);
Sat, 18 Mar 89 19:19:40 CST id AA10441 for cl-cleanup@SAIL.STANFORD.EDU
Posted-Date: Sat, 18 Mar 89 19:17:51 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
id AA20309; Sat, 18 Mar 89 19:17:51 CST
Date: Sat, 18 Mar 89 19:17:51 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8903190117.AA20309@pavo.src.honeywell.com>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: masinter.pa@Xerox.COM's message of 16 Mar 89 08:19 PST <890316-082029-3881@Xerox>
Subject: Issue DESCRIBE-UNDERSPECIFIED, v.1
REMARKS:
Methods on DESCRIBE-OBJECT may recursively call DESCRIBE. Indentation,
depth limits, and circularity detection are all taken care of automatically,
provided that each method handles exactly one level of structure and calls
DESCRIBE recursively argument if there are more structural levels.
Something is missing on the last line. Was there supposed to be a
recursivep argument?
∂18-Mar-89 2312 CL-Cleanup-mailer Issue: DEFMACRO-LAMBDA-LIST, v.2
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 Mar 89 23:12:38 PST
Received: from ISABEL-PERON.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 182861; Sun 19-Mar-89 01:25:45 EST
Date: Sun, 19 Mar 89 01:28 EST
From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
Subject: Issue: DEFMACRO-LAMBDA-LIST, v.2
To: masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu
In-Reply-To: <890317-195034-3172@Xerox>
Message-ID: <19890319062819.3.MLY@ISABEL-PERON.AI.MIT.EDU>
1. a. Specify that &BODY may appear at any level of a DEFMACRO lambda list.
b. Specify that &WHOLE may only appear at any level of a DEFMACRO
lambda list. At inner levels, the &WHOLE variable is bound to
``May only appear at any level'' sounds like a control-Y bug.
c. Specify that &ENVIRONMENT may only appear at the top level of a
DEFMACRO lambda list.
Something else which needs to be clarified is where the &ENVIRONMENT
keyword may appear.
Which of the following are legal?
1. (defmacro foo (&whole w &environment e a b) ...)
2. (defmacro foo (&environment e &whole w a b) ...)
3. (defmacro foo (&whole w a b &environment e) ...)
4. (defmacro foo (&whole w a &environment e b) ...)
I'd like to say 1,2 and 3 only, even though case 2 would require some
modification of the ``first in the lambda-list'' terminology.
∂19-Mar-89 1058 CL-Cleanup-mailer Issue: HASH-TABLE-ACCESS (version 2)
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 19 Mar 89 10:58:19 PST
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88);
Sun, 19 Mar 89 12:57:12 CST id AA11401 for cl-cleanup@sail.stanford.edu
Posted-Date: Sun, 19 Mar 89 12:55:24 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
id AA20779; Sun, 19 Mar 89 12:55:24 CST
Date: Sun, 19 Mar 89 12:55:24 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8903191855.AA20779@pavo.src.honeywell.com>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 16 Mar 89 22:51 PST <890316-225136-6875@Xerox>
Subject: Issue: HASH-TABLE-ACCESS (version 2)
HASH-TABLE-REHASH-SIZE hash-table
Returns the current rehash size of a hash table.
Two minor nits, first the wording should say "of the hash-table", and
secondly the results of passing in a non hash table should be described,
e.g. signals an error, or is undefined. I think having portable access to
the HASH-TABLE-TEST is quite important, I would hate to loose the chance to
get that because of the other functions, but I guess that an ammendment on
the floor could remove the ones people have trouble with.
∂20-Mar-89 1229 CL-Cleanup-mailer Re: Issue: PRETTY-PRINT-INTERFACE (version 3)
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 20 Mar 89 12:29:22 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA00470; Mon, 20 Mar 89 10:13:54 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA01358; Mon, 20 Mar 89 10:15:47 EST
Message-Id: <8903201515.AA01358@mist.>
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: PRETTY-PRINT-INTERFACE (version 3)
In-Reply-To: Your message of Sat, 18 Mar 89 01:32:00 -0500.
<19890318063223.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 20 Mar 89 10:15:45 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Date: Sat, 18 Mar 89 01:32 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
I could not find any specification of the units of measurement for
*PRINT-RIGHT-MARGIN*, *DEFAULT-RIGHT-MARGIN*, *PRINT-MISER-WIDTH*,
indentation, and tabulation. It's not even clear that margins,
indentation, and tabulation can't be measured in three different
units. Analysis of the examples suggests that the units are
assumed to be characters and all characters are assumed to be the
same width. This is not an implementation-independent assumption.
In any case the proposal has to be specific about the units. I
would prefer something that seamlessly accomodates variable-width
characters, but don't have enough experience with pretty-printers
to propose anything myself.
I think that all three clearly have to be in the same units; the
writeup should be changed to specify this. After thinking about it
for a while, it's not clear that the exact unit matters much as long
as it's not to small. Pixels are too small; "n"'s or "m"'s aren't.
Personally I'd suggest an "m" as the standard unit.
Other than that, I don't think the propsal has terrible problems with
variable width (even kerned) fonts because most indentation is done
relative to the position of the start of another word. This common
case can be handled with arbitrary precision; a variable width font
implementation would presumably indent to the exact pixel position of
the relevant character (how would that be expressed in Postscript?).
Of course parts of the proposal won't work for right-to-left or
top-to-bottom languages. I think that rejecting the proposal because
of that would be ridiculous.
∂20-Mar-89 1236 CL-Cleanup-mailer Re: Issue: PRETTY-PRINT-INTERFACE (version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89 12:36:46 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561205; Mon 20-Mar-89 15:35:05 EST
Date: Mon, 20 Mar 89 15:34 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PRETTY-PRINT-INTERFACE (version 3)
To: Dan L. Pierson <pierson@mist.encore.com>
cc: cl-cleanup@SAIL.STANFORD.EDU, disk@wheaties.ai.mit.edu
In-Reply-To: <8903201515.AA01358@mist.>
Message-ID: <19890320203457.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 20 Mar 89 10:15:45 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Date: Sat, 18 Mar 89 01:32 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
I could not find any specification of the units of measurement for
*PRINT-RIGHT-MARGIN*, *DEFAULT-RIGHT-MARGIN*, *PRINT-MISER-WIDTH*,
indentation, and tabulation.
I think that all three clearly have to be in the same units; the
writeup should be changed to specify this. After thinking about it
for a while, it's not clear that the exact unit matters much as long
as it's not to small. Pixels are too small; "n"'s or "m"'s aren't.
Personally I'd suggest an "m" as the standard unit.
I don't see anything wrong with that, although I can't claim to be an
expert in this area.
Other than that, I don't think the propsal has terrible problems with
variable width (even kerned) fonts because most indentation is done
relative to the position of the start of another word. This common
case can be handled with arbitrary precision; a variable width font
implementation would presumably indent to the exact pixel position of
the relevant character (how would that be expressed in Postscript?).
I think what you're saying is that the argument to LOGICAL-BLOCK-INDENT
(or ~I) is almost always zero? In the examples given in version 1
of the proposal, zero is in the majority, there are also two 1's and
a 2. I didn't find any cases where the number given to ~I seemed to
be intended to correspond to the number of characters in some word.
There might need to be a style suggestion for writers of pretty print
methods telling them to use relative indentation instead of counting
characters. Given that, your suggestion sounds plausible to me.
∂20-Mar-89 1241 CL-Cleanup-mailer Issue: COMPLEX-RATIONAL-RESULT (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89 12:40:41 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560964; Mon 20-Mar-89 11:41:43 EST
Date: Mon, 20 Mar 89 11:41 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COMPLEX-RATIONAL-RESULT (version 1)
To: CL-Cleanup@sail.stanford.edu
cc: chapman%aitg.DEC@decwrl.dec.com
Message-ID: <19890320164136.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
This issue came up while reviewing section 2.2 of the draft standard.
Does anyone object if I mail this to X3J13 and bring it up at the
March meeting? I couldn't find any sign that it has already been addressed.
Issue: COMPLEX-RATIONAL-RESULT
References: CLtL p.203
Category: CLARIFICATION
Edit history: Version 1, 20-Mar-89, by Moon
Problem description:
Referring to irrational and transcendental functions, CLtL says:
When the arguments to a function in this section are all rational and
the true mathematical result is also (mathematically) rational, then
unless otherwise noted an implementation is free to return either an
accurate result of type rational or a single-precision floating-point
approximation. If the arguments are all rational but the result cannot
be expressed as a rational number, then a single-precision
floating-point approximation is always returned.
Referring to EXPT, CLtL says:
If the base-number is of type RATIONAL and the power-number is an
INTEGER, the calculation will be exact and the result will be of
type RATIONAL; otherwise a floating-point approximation may result.
What about arguments of type (complex rational)?
Proposal (COMPLEX-RATIONAL-RESULT:EXTEND):
Extend the paragraph quoted above to cover the components of complex
numbers. For (complex rational) arguments, a mathematically rational
result can be rational, (complex rational), or (complex float) at the
discretion of the implementation. For EXPT of a (complex rational) to
an integer power, the calculation must be exact and the result will
be rational or (complex rational).
Examples:
(log #c(-16 16) #c(2 2)) => 3 or approximately #c(3.0 0.0)
(expt #c(2 2) 3) => #c(-16 16)
(expt #c(2 2) 4) => -64
Rationale:
This seems most consistent with the treatment of real numbers.
Current practice:
Symbolics Genera 7.4 returns a (complex float) for the first example
and returns the specified answers for the second and third examples.
Other implementations were not surveyed.
Cost to Implementors:
Only EXPT would have to change, since the type of the other results
is at the discretion of the implementation.
Cost to Users:
Probably none, but it is hard to predict.
Cost of non-adoption:
Slightly less self-consistent language.
Performance impact:
None of any significance.
Benefits/Esthetics:
More self-consistent language.
Discussion:
None.
∂20-Mar-89 1241 CL-Cleanup-mailer Issue: HASH-TABLE-SIZE (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89 12:41:39 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560978; Mon 20-Mar-89 11:55:18 EST
Date: Mon, 20 Mar 89 11:55 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-SIZE (version 1)
To: CL-Cleanup@sail.stanford.edu
cc: chapman%aitg.DEC@decwrl.dec.com
Message-ID: <19890320165503.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
This issue came up while reviewing section 2.2 of the draft standard.
Does anyone object if I mail this to X3J13 and bring it up at the
March meeting? I couldn't find any sign that it has already been addressed.
Issue: HASH-TABLE-SIZE
References: CLtL p.283
Category: CLARIFICATION
Edit history: Version 1, 20-Mar-89, by Moon
Problem description:
CLtL contradicts itself on the meaning of the :SIZE argument to
MAKE-HASH-TABLE. At the top of p.283, it says that the size is "the
maximum number of entries it can hold. Usually the actual capacity of
the table is somewhat less." At the bottom of the page it says "this
argument serves as a hint to the implementation of approximately how
many entries you intend to store." So does the :SIZE intended to be the
actual capacity of the table, or the amount of storage allocated to hold
the table. For example, if the implementation of hash tables is
designed for a loading of 65%, and the user specifies :SIZE 100, does
the table returned have space allocated for 100 entries, so that it
overflows and becomes bigger when 65 entries are inserted, or does the
table have space allocated for 154 entries, so that it overflows and
becomes bigger when 100 entries are inserted?
Proposal (HASH-TABLE-SIZE:INTENDED-ENTRIES):
Believe the bottom of p.283 rather than the top. The :SIZE argument
is approximately the number of entries that can be inserted without
the table having to grow.
Rationale:
The bottom of p.283 is user-oriented, the top is implementation-oriented.
User-oriented seems more appropriate.
Current practice:
Symbolics Genera 7.4 adheres to HASH-TABLE-SIZE:INTENDED-ENTRIES.
Other implementations were not surveyed.
Cost to Implementors:
At worst adding a multiplication to MAKE-HASH-TABLE.
Cost to Users:
Probably none, but it is hard to predict.
Cost of non-adoption:
Implementations will probably vary in which of the two interpretations
they believe. The language standard will not be self-consistent.
Performance impact:
None of any significance.
Benefits/Esthetics:
More self-consistent language.
Discussion:
None.
∂20-Mar-89 1242 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-VALUE (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89 12:41:44 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561033; Mon 20-Mar-89 13:04:18 EST
Date: Mon, 20 Mar 89 13:04 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-COMPONENT-VALUE (version 1)
To: CL-Cleanup@sail.stanford.edu
cc: chapman%aitg.DEC@decwrl.dec.com
Message-ID: <19890320180405.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
This issue came up while reviewing section 2.2 of the draft standard.
Does anyone object if I mail this to X3J13 and bring it up at the
March meeting? I couldn't find any sign that it has already been addressed.
Issue: PATHNAME-COMPONENT-VALUE
Related Issues:PATHNAME-CANONICAL-TYPE,
PATHNAME-SUBDIRECTORY-LIST,
PATHNAME-UNSPECIFIC-COMPONENT,
PATHNAME-WILD
References: CLtL pp.410-3
Category: CLARIFICATION and CHANGE
Edit history: Version 1, 20-Mar-89, by Moon
Problem description:
CLtL is overly restrictive on the possible values for pathname components.
These restrictions are described in a funny way that makes it unclear
whether they are requirements, guidelines, or just an example.
The restrictions are not all written down in one place, but they appear
to be as follows:
Host nil, :wild, string, or list of strings
Device nil, :wild, string, or something else ("structured")
Directory nil, :wild, string, or something else ("structured")
Name nil, :wild, string, or something else ("structured")
Type nil, :wild, or string
Version nil, :wild, :newest, positive integer, implementation
dependent symbol, or implementation-dependent integer
less than or equal to zero. Suggestions include :oldest,
:previous, :installed, 0, and -1.
PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN allowed implementations to
allow any component to be :UNSPECIFIC. This has been voted in.
PATHNAME-SUBDIRECTORY-LIST proposes a list of strings and keyword
symbols for the directory component.
PATHNAME-CANONICAL-TYPE proposes some new operations but does not
change the possible values of the type component.
PATHNAME-WILD proposes a portable way to test for implementation
dependent component values that indicate wildcard matching. It
does not change the possible values of any component.
Proposal (PATHNAME-COMPONENT-VALUE:SPECIFY):
The points of the proposal have been numbered to facilitate
amendments to remove or modify individual points.
When examining pathname components, conforming programs must be
prepared to encounter any of the following values:
1. Any component can be NIL, which means the component has not
been specified.
2. Any component can be :UNSPECIFIC, which means the component has
no meaning in this particular pathname.
3. Any component can be :WILD, which matches any component value.
Wild pathnames can be used with DIRECTORY but not with OPEN.
4. The host, device, directory, name, and type can be strings.
5. The host and device can be a list, a structure, or a
standard-object at the discretion of the implementation.
6. The directory can be a list of strings and symbols as detailed in
PATHNAME-SUBDIRECTORY-LIST (this assumes that it passes.)
7. The version can be any symbol or any integer. The symbol :NEWEST
refers to the largest version number that already exists in the file
system when reading, overwriting, appending, superseding, or directory
listing an existing file, and refers to the smallest version number
greater than any existing version number when creating a new file.
When constructing a pathname from components, conforming programs
must follow these rules:
11. Any component can be NIL. NIL in the host may mean a default host
rather than an actual NIL in some implementations.
12. Any component can be :WILD, which matches any component value.
Wild pathnames can be used with DIRECTORY but not with OPEN.
13. The host, device, directory, name, and type can be strings.
14. The directory can be a list of strings and symbols as detailed in
PATHNAME-SUBDIRECTORY-LIST (this assumes that it passes.)
15. The version can be :NEWEST.
16. Any component can be taken from the corresponding component
of another pathname on the same host and device.
17. An implementation might support other values for some
components, but a portable program cannot use those values.
An implementation might allow values to be transferred between
pathnames on different hosts or different devices, but a portable
program cannot rely on that.
A conforming program can use implementation-dependent values
but this can make it non-portable, for example, it might work
only with Unix file systems.
18. It is suggested, but not required, that implementations use
positive integers starting at 1 as version numbers, recognize
the symbol :oldest to designate the smallest existing version
number, and use keyword symbols for other special versions.
Consequences:
The changes relative to CLtL plus PATHNAME-UNSPECIFIC-COMPONENT
are as follows:
The definition of "structured" component is restricted to lists,
structures, and standard-objects, rather than allowing any object
whatsoever.
"Structured" hosts are allowed, a generalization of CLtL's list
of strings.
"Structured" directories are replaced by PATHNAME-SUBDIRECTORY-LIST.
"Structured" names are forbidden.
The difference between what component values a program can depend
on being able to use, versus what component values a program must
be prepared to encounter, is clarified.
Rationale:
This should make it easier to write portable programs that deal with
pathnames and make it easier for implementors by clarifying the
framework into which they must fit. Also it should make it easier
to write the Common Lisp language specification by resolving some
things that were unclear about the status quo.
Adding "structured" hosts conforms to current practice.
Substituting a default host for NIL conforms to current practice
in implementations that require all pathnames to have a specific host.
Removing "structured" names should improve portability without causing
any harm, assuming no implementation uses structured names. This will
improve portability by allowing programs to do string manipulation on
names, although such programs still have to be careful since the valid
characters and maximum length of a name are implementation-dependent.
Disallowing transferral of nonstandard component values between
different hosts or different devices allows implementations to support
multiple incompatible file systems.
Current practice:
All versions of Symbolics Genera violate CLtL in the matter of hosts,
since it uses standard-objects as the host component. Genera deviates
slightly from PATHNAME-SUBDIRECTORY-LIST, but otherwise conforms to
PATHNAME-COMPONENT-VALUE:SPECIFY.
Other implementations were not surveyed.
This proposal assumes that no current or planned implementation
uses structured names, not even for wildcards.
Cost to Implementors:
Most implementations already conform, except for the changes required
by PATHNAME-UNSPECIFIC-COMPONENT and PATHNAME-SUBDIRECTORY-LIST, so
the cost of this proposal itself should be minimal. It is conceivable
that an implementation may exist that has to change its pathname
representation, for example one that uses numbers as structured devices.
Cost to Users:
None.
Cost of non-adoption:
Pathnames will continue to be a poorly specified part of the language.
Performance impact:
None of any significance.
Benefits/Esthetics:
The boundary between the specified behavior of pathnames and the
implementation-dependent behavior of pathnames will be more clear.
Discussion:
None.
∂20-Mar-89 1241 CL-Cleanup-mailer Issue: COMMON-TYPE (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89 12:40:49 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560953; Mon 20-Mar-89 11:24:20 EST
Date: Mon, 20 Mar 89 11:24 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COMMON-TYPE (version 1)
To: CL-Cleanup@sail.stanford.edu
cc: chapman%aitg.DEC@decwrl.dec.com
Message-ID: <19890320162410.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
This issue came up while reviewing section 2.2 of the draft standard.
Does anyone object if I mail this to X3J13 and bring it up at the
March meeting? I couldn't find any sign that it has already been addressed.
Issue: COMMON-TYPE
References: CLtL p.35, p.76
Category: CHANGE
Edit history: Version 1, 20-Mar-89, by Moon
Problem description:
The type COMMON is defined in a very peculiar way and does not seem to
be useful for anything. It can be extended by users using DEFSTRUCT,
but not DEFTYPE nor DEFCLASS, but it cannot be extended by implementations.
Whether certain types such as NUMBER and ARRAY are subtypes of COMMON
is implementation-dependent. The goal of having the COMMON type was
probably to improve portability, but it is unclear how it could actually
be used in that way.
Proposal (COMMON-TYPE:REMOVE):
Remove COMMON and COMMONP from the language.
Rationale:
Keeping the definition of COMMON accurate in the new specification, in
the face of changes elsewhere in the language such as the introduction
of CLOS and the possible introduction of character registries, is
difficult when no one is sure what COMMON is for. If no one uses COMMON,
it would be less work to just get rid of it.
Current practice:
Every implementation probably implements COMMON. Moon has never seen it
used except in a program to test whether its implementation matched CLtL.
Cost to Implementors:
None.
Cost to Users:
None unless they are actually using COMMON.
Cost of non-adoption:
Implementors would have to maintain COMMON. Users would have to try to
understand it, or figure out that they didn't care about it.
Performance impact:
None.
Benefits:
Simpler language.
Esthetics:
Simpler language.
Discussion:
None.
∂20-Mar-89 1325 CL-Cleanup-mailer Re: Issue: LOAD-OBJECTS (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 20 Mar 89 13:24:54 PST
Received: from Semillon.ms by ArpaGateway.ms ; 20 MAR 89 13:17:33 PST
Date: 20 Mar 89 13:16 PST
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Subject: Re: Issue: LOAD-OBJECTS (Version 3)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Sat, 18 Mar 89 01:50 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>, Richard P. Gabriel
<rpg@lucid.com>, CL-Cleanup@sail.stanford.edu,
CL-Compiler@sail.stanford.edu, Common-Lisp-Object-System@sail.stanford.edu
Message-ID: <890320-131733-6488@Xerox>
MAKE-LOAD-FORM-USING-SLOTS is too easy to confuse with
SLOT-VALUE-USING-CLASS. MAKE-LOAD-FORM-FROM-SLOTS is better,
except for form/from dyslexia. MAKE-LOAD-FORM-FOR-SLOTS ?
How about MAKE-LOAD-FORM-SAVING-SLOTS
danny
∂20-Mar-89 1415 CL-Cleanup-mailer Re: Issue: PRETTY-PRINT-INTERFACE (version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89 14:15:08 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561357; Mon 20-Mar-89 17:13:50 EST
Date: Mon, 20 Mar 89 17:13 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PRETTY-PRINT-INTERFACE (version 3)
To: Dan L. Pierson <pierson@mist.encore.com>
cc: cl-cleanup@SAIL.STANFORD.EDU, dick@wheaties.ai.mit.edu
In-Reply-To: <8903201515.AA01358@mist.>
Supersedes: <19890320203457.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comments: Resend after correcting misspelling in Dick Waters' mailbox name.
Message-ID: <19890320221342.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 20 Mar 89 10:15:45 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Date: Sat, 18 Mar 89 01:32 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
I could not find any specification of the units of measurement for
*PRINT-RIGHT-MARGIN*, *DEFAULT-RIGHT-MARGIN*, *PRINT-MISER-WIDTH*,
indentation, and tabulation.
I think that all three clearly have to be in the same units; the
writeup should be changed to specify this. After thinking about it
for a while, it's not clear that the exact unit matters much as long
as it's not to small. Pixels are too small; "n"'s or "m"'s aren't.
Personally I'd suggest an "m" as the standard unit.
I don't see anything wrong with that, although I can't claim to be an
expert in this area.
Other than that, I don't think the propsal has terrible problems with
variable width (even kerned) fonts because most indentation is done
relative to the position of the start of another word. This common
case can be handled with arbitrary precision; a variable width font
implementation would presumably indent to the exact pixel position of
the relevant character (how would that be expressed in Postscript?).
I think what you're saying is that the argument to LOGICAL-BLOCK-INDENT
(or ~I) is almost always zero? In the examples given in version 1
of the proposal, zero is in the majority, there are also two 1's and
a 2. I didn't find any cases where the number given to ~I seemed to
be intended to correspond to the number of characters in some word.
There might need to be a style suggestion for writers of pretty print
methods telling them to use relative indentation instead of counting
characters. Given that, your suggestion sounds plausible to me.
∂20-Mar-89 1427 CL-Cleanup-mailer Re: Issue: LOAD-OBJECTS (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89 14:27:09 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561368; Mon 20-Mar-89 17:23:27 EST
Date: Mon, 20 Mar 89 17:23 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: LOAD-OBJECTS (Version 3)
To: Danny Bobrow <Bobrow.pa@XEROX.COM>
cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>, Richard P. Gabriel <rpg@lucid.com>,
CL-Cleanup@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU, Common-Lisp-Object-System@SAIL.STANFORD.EDU
In-Reply-To: <890320-131733-6488@Xerox>
Message-ID: <19890320222313.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 20 Mar 89 13:16 PST
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
MAKE-LOAD-FORM-USING-SLOTS is too easy to confuse with
SLOT-VALUE-USING-CLASS. MAKE-LOAD-FORM-FROM-SLOTS is better,
except for form/from dyslexia. MAKE-LOAD-FORM-FOR-SLOTS ?
How about MAKE-LOAD-FORM-SAVING-SLOTS
I like that name.
∂20-Mar-89 1437 CL-Cleanup-mailer Issue: COMMON-TYPE (version 1)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 20 Mar 89 14:36:39 PST
Received: from fafnir.think.com by Think.COM; Mon, 20 Mar 89 17:27:04 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 20 Mar 89 17:28:00 EST
Received: by verdi.think.com; Mon, 20 Mar 89 17:24:46 EST
Date: Mon, 20 Mar 89 17:24:46 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903202224.AA19319@verdi.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu, chapman%aitg.DEC@decwrl.dec.com
In-Reply-To: David A. Moon's message of Mon, 20 Mar 89 11:24 EST <19890320162410.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: COMMON-TYPE (version 1)
I support COMMON-TYPE:REMOVE.
∂20-Mar-89 1438 CL-Cleanup-mailer Issue: COMMON-TYPE (version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 20 Mar 89 14:38:37 PST
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA05260g; Mon, 20 Mar 89 14:33:18 PST
Received: by blacksox id AA00779g; Mon, 20 Mar 89 14:38:08 PST
Date: Mon, 20 Mar 89 14:38:08 PST
From: Eric Benson <eb@lucid.com>
Message-Id: <8903202238.AA00779@blacksox>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@sail.stanford.edu, chapman%aitg.DEC@decwrl.dec.com
In-Reply-To: David A. Moon's message of Mon, 20 Mar 89 11:24 EST <19890320162410.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: COMMON-TYPE (version 1)
Yes, yes, yes. COMMON is useless. I'm sure Guy thought it would be
useful, but it isn't. Burn it. It has not survived the test of time.
∂20-Mar-89 1507 CL-Cleanup-mailer Issue: COMPLEX-RATIONAL-RESULT (version 1)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 20 Mar 89 15:06:39 PST
Received: from fafnir.think.com by Think.COM; Mon, 20 Mar 89 17:29:50 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 20 Mar 89 17:30:06 EST
Received: by verdi.think.com; Mon, 20 Mar 89 17:26:47 EST
Date: Mon, 20 Mar 89 17:26:47 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903202226.AA19323@verdi.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu, chapman%aitg.DEC@decwrl.dec.com
In-Reply-To: David A. Moon's message of Mon, 20 Mar 89 11:41 EST <19890320164136.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: COMPLEX-RATIONAL-RESULT (version 1)
I support COMPLEX-RATIONAL-RESULT:EXTEND.
∂20-Mar-89 1512 CL-Cleanup-mailer Issue: HASH-TABLE-SIZE (version 1)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 20 Mar 89 15:10:34 PST
Received: from fafnir.think.com by Think.COM; Mon, 20 Mar 89 17:31:49 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 20 Mar 89 17:31:12 EST
Received: by verdi.think.com; Mon, 20 Mar 89 17:27:56 EST
Date: Mon, 20 Mar 89 17:27:56 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903202227.AA19331@verdi.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu, chapman%aitg.DEC@decwrl.dec.com
In-Reply-To: David A. Moon's message of Mon, 20 Mar 89 11:55 EST <19890320165503.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-SIZE (version 1)
I support HASH-TABLE-SIZE:INTENDED-ENTRIES.
∂20-Mar-89 1556 CL-Cleanup-mailer Issue: PRETTY-PRINT-INTERFACE (version 3)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Mar 89 15:55:52 PST
Received: from wheat-chex.ai.mit.edu by life.ai.mit.edu; Mon, 20 Mar 89 18:54:57 EST
Received: from localhost by wheat-chex.ai.mit.edu; Mon, 20 Mar 89 18:54:55 EST
Date: Mon, 20 Mar 89 18:54:55 EST
From: dick@wheaties.ai.mit.edu
Message-Id: <8903202354.AA04220@wheat-chex.ai.mit.edu>
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: gls@think.com, cl-cleanup@sail.stanford.edu, dick@wheaties.ai.mit.edu
Subject: Issue: PRETTY-PRINT-INTERFACE (version 3)
RE: your recent comments.
(1) Clearly, the right statements about length units need to be put in
the proposal. A note advising programmers to use explicit lengths as
little as possible also sounds like a good idea.
(2) I agree that it was a severe error to omit the funcional interface.
However, I also think it would be a severe error to omit the format interface.
(3) I understand why you would like to have define-print-dispatch
merged with the CLOS stuff. I will look into that. (Can you
remind me of the issue of SIGPLAN notices that CLOS was described
in? Is that accurate?) However, I think there may be problems.
First, although not particularly shown in the examples, I have
found very elaborate type specifies for printing things (e.g.,
including satisfies clauses) to be quite useful. In the proposal
note the use of the specifier (CONS (AND SYMBOL (SATISFIES FBOUNDP))).
Also note the use of priorities to disambiguate between overlapping
type specifiers. This is very important to get propper
defaulting---i.e. specifying how to print lists in general as well
as particular special forms. Maybe some inheretence things can
make that work in CLOS, but it is not clear to me.
Finally although it can certainly work, passing style of
printing arguments around does not appeal to me anywhere near as
much as multiple dispatch tables, because
when you write your first style, you have to set things up to
allow for more styles even if you never have more styles, or else
face a lot of work when you make a second style. It is also not
clear how this would all fit in with having a standard predefined
style that users can modify as they wish.
It seems to me that the pretty printer and CLOS just do not have
the same idea of what an object is, and that while CLOS primarily
has a quasi-static association of methods to objects, the pretty
printer wants to support rapid wholesale change. Given these
differences, unification may not work as well as one might hope.
(4) Your suggestions for improving the functional interface basically
sound good to me, however I differ slightly with a couple of them.
Combining the :stream and :var sounds like a good idea.
However, The :arg argument is not mandatory. It is not used in the
second example I sent around with the functional interface proposal.
I think that making :prefix, :per-line-prefix, and :suffix functions
is overkill. One can always use #. after all.
Changing the name of :from-start and :from-position and the argument
sounds fine to me.
note that ~/tabular-style/ etc. uses the format interface for
calling a function. Therefore it has already been implicitly
stated that tabular-style, fill-style, and linear-style, are
functions and what their arguments are. The definition of the
function linear-style is given as an example, and fill-style is
used as a function in another example in the original proposal.
Nevertheless, the functional interface part should note that they
are functions.
∂20-Mar-89 1605 CL-Cleanup-mailer Issue: FIXNUM-NON-PORTABLE, v.5
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 20 Mar 89 16:04:01 PST
Received: from fafnir.think.com by Think.COM; Mon, 20 Mar 89 11:47:53 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 20 Mar 89 11:48:52 EST
Received: by verdi.think.com; Mon, 20 Mar 89 11:45:31 EST
Date: Mon, 20 Mar 89 11:45:31 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903201645.AA17143@verdi.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Fri, 17 Mar 89 19:53 EST <19890318005344.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: FIXNUM-NON-PORTABLE, v.5
Date: Fri, 17 Mar 89 19:53 EST
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Date: 16 Mar 89 21:51 PST
From: masinter.pa@Xerox.COM
This is my rewrite to capture the 'intent' of the amendment
at the January X3J13. I say 'intent' because the relation
between MOST-POSITIVE-FIXNUM (which is an inclusive bound)
and ARRAY-DIMENSION-LIMIT (which is an exclusive bound) is not
> but rather (>= MOST-POSITIVE-FIXNUM (1- ARRAY-DIMENSION-LIMIT)).
No, the amendment was (<= ARRAY-DIMENSION-LIMIT MOST-POSITIVE-FIXNUM),
and this was not a mistake nor an off-by-one error. What you've
put in the proposal here is incorrect, I think. I think it was
fully intended that not only every valid array index and every
array dimension, but also array-dimension-limit itself would be
a fixnum. Someone might want to write an arithmetic iteration
whose upper bound was array-dimension-limit.
I agree with Moon's observations and assessment; this was my understanding
of the amendment.
Pascal-type languages have had no end of grief because iteration counters
take on "invalid" (read "non-fixnum" here and you'll get the idea) values
at the end of the last iteration.
--Guy
∂20-Mar-89 1841 CL-Cleanup-mailer Issue: PRETTY-PRINT-INTERFACE (version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89 18:41:21 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561599; Mon 20-Mar-89 21:39:43 EST
Date: Mon, 20 Mar 89 21:39 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PRETTY-PRINT-INTERFACE (version 3)
To: dick@wheaties.ai.mit.edu
cc: gls@think.com, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8903202354.AA04220@wheat-chex.ai.mit.edu>
Message-ID: <19890321023936.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 20 Mar 89 18:54:55 EST
From: dick@wheaties.ai.mit.edu
....
(Can you
remind me of the issue of SIGPLAN notices that CLOS was described
in? Is that accurate?)
SIGPlan Notices (ISSN 0362-1340)
Volume 23
Special Issue -- September 1988
ISBN 0-89791-289-6
ACM Order Number 548883
I don't know whether it's accurate, I haven't looked at it. I imagine
it is an exact copy of X3J13 document 88-002R, which is pretty close.
(3) I understand why you would like to have define-print-dispatch
merged with the CLOS stuff. I will look into that. However, I think there may be problems.
First, although not particularly shown in the examples, I have
found very elaborate type specifies for printing things (e.g.,
including satisfies clauses) to be quite useful. In the proposal
note the use of the specifier (CONS (AND SYMBOL (SATISFIES FBOUNDP))).
Also note the use of priorities to disambiguate between overlapping
type specifiers. This is very important to get propper
defaulting---i.e. specifying how to print lists in general as well
as particular special forms. Maybe some inheretence things can
make that work in CLOS, but it is not clear to me.
So what you're saying is that you want to use type specifiers that have
unclear subtype/supertype relationships, and compensate for that by
using numerical priorities. I understand now. CLOS cannot currently
handle that through the normal parameter specializer mechanism, because
it requires clear subtype/supertype relationships from the type
specifiers alone. On the other hand, one could make a form of method
combination that did the same thing as define-print-dispatch, but that
would be going through the back door. On the third hand, some of the
applicability testing could be moved into the body of the method and
call-next-method employed.
At this point I don't know what to say; expediency and elegance seem
to be in direct conflict. Maybe someone else has an idea. I certainly
will not block the thing for this point of esthetics, but it does raise
a red flag for me that something somewhere is inadequate.
Finally although it can certainly work, passing style of
printing arguments around does not appeal to me anywhere near as
much as multiple dispatch tables, because
when you write your first style, you have to set things up to
allow for more styles even if you never have more styles, or else
face a lot of work when you make a second style. It is also not
clear how this would all fit in with having a standard predefined
style that users can modify as they wish.
I think if you think about this harder you'll realize that dispatch tables
and style-of-printing arguments are isomorphic and differ only in some
minor internal implementation details.
It seems to me that the pretty printer and CLOS just do not have
the same idea of what an object is, and that while CLOS primarily
has a quasi-static association of methods to objects, the pretty
printer wants to support rapid wholesale change. Given these
differences, unification may not work as well as one might hope.
I think this is a non-issue, but the real problem is what you said above
complex type specifiers.
(4) Your suggestions for improving the functional interface basically
sound good to me, however I differ slightly with a couple of them.
Combining the :stream and :var sounds like a good idea.
However, The :arg argument is not mandatory. It is not used in the
second example I sent around with the functional interface proposal.
I don't recall seeing any examples of the functional interface. Let me
ask, how frequently is the :arg argument omitted? If it's omitted very
infrequently, it would be better to supply an explicit nil in those cases
than to say :arg in all the rest of the cases.
I think that making :prefix, :per-line-prefix, and :suffix functions
is overkill. One can always use #. after all.
No, the issue is a function that decides at run time what to output, rather
than having a canned string. Whether the string appears in the source or
is generated at compile time is of no moment. But if you don't want to
put in the extra flexibility, I won't complain, I don't have a specific
use for it in mind, I only proposed it on general principles.
∂20-Mar-89 2059 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-VALUE (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89 20:59:17 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561655; Mon 20-Mar-89 23:36:27 EST
Date: Mon, 20 Mar 89 23:36 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-COMPONENT-VALUE (version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: chapman%aitg.DEC@decwrl.dec.com
In-Reply-To: <19890320180405.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890321043621.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
When constructing a pathname from components, conforming programs
must follow these rules:
16. Any component can be taken from the corresponding component
of another pathname on the same host and device.
A possible alternative that's worth considering is:
16. Any component can be taken from the corresponding component
of another pathname. When the two pathnames are for incompatible
file systems (in implementations that support multiple file
systems), an appropriate translation occurs. If no meaningful
translation is possible, an error is signalled. The definition
of "appropriate" and "meaningful" is implementation-dependent.
This provides more useful behavior that conforming programs can
depend upon, but the behavior cannot be as precisely specified.
A significant amount of the Symbolics Genera pathname facility is
related to this capability, and it's used a lot in heterogeneous
networks, so maybe this is a useful capability that ought to be
called for in the language. The cost to implementors is small since
they could define "appropriate" and "meaningful" to be whatever is
easiest for them, if their users don't complain.
∂21-Mar-89 0845 CL-Cleanup-mailer Issue: GENSYM-NAME-STICKINESS (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Mar 89 08:45:45 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561958; Tue 21-Mar-89 11:45:31 EST
Date: Tue, 21 Mar 89 11:45 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: GENSYM-NAME-STICKINESS (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890321114510.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Hopefully this is a final version, ready for vote.
Guy has already reviewed it and approves of the changes
(removing GENSYM-COUNTER, adding variable *GENSYM-COUNTER*).
-kmp
-----
Issue: GENSYM-NAME-STICKINESS
Forum: Cleanup
References: GENSYM (p169)
Category: CHANGE
Edit history: 14-Feb-89, Version 1 by Pitman
15-Mar-89, Version 2 by Steele (add GENSYM-COUNTER function)
20-Mar-89, Version 3 by Pitman (make it a variable)
Problem Description:
Many people avoid use of the argument to GENSYM because the argument
is `sticky' and such stickiness can lead to confusion. The problem is
that if any application (usually a macro) uses the gensym argument at
all, then all applications are forced to. If they do not, they risk
finding that the `helpful' argument supplied in some previous call will
be harmful to them.
Proposal (GENSYM-NAME-STICKINESS:LIKE-TEFLON)
Define that if an optional argument [either a string or a number] is
given to GENSYM, it does NOT have a side-effect on GENSYM's internal state.
Introduce a new variable, *GENSYM-COUNTER*, which holds the state of
the gensym counter. That is, the next symbol generated by GENSYM will
be number n. The initial value of this variable is not defined, but
must always be a non-negative integer. This variable may be either
assigned or bound by users at any time, but always to a non-negative
integer.
Deprecate the use of a numeric argument to GENSYM.
Rationale:
Conscientious programmers are forced now to write their own GENSYM
lookalikes because they know the system's GENSYM has an invasive
effect. This defeats the primary intended function of GENSYM, which
is to satisfy the most common idiomatic use of MAKE-SYMBOL.
The stickiness of the GENSYM prefix was an attempt to be gratuitously
compatible with Maclisp, at the expense of good programming pratice.
Users who need the old behavior of GENSYM can trivially implement
that behavior using MAKE-SYMBOL.
Occasionally you want to reset the GENSYM counter so that, for example,
you can get the compiler to generate the same symbol names again
(good for comparing results to see what really changed).
Test Case:
;; #1: Test stickiness of name part.
(CHAR-EQUAL (CHAR (SYMBOL-NAME (SECOND (LIST (GENSYM "A") (GENSYM)))) 0)
#\G)
=> NIL ;under CLtL
=> T ;under this proposal
;; #2: Test stickiness of number part.
(= (PARSE-INTEGER (PROGN (GENSYM 6789) (STRING (GENSYM "G"))) :START 1)
6790)
=> T ;under CLtL
=> NIL ;under this proposal (except when *gensym-counter* happens to align)
;; #3: Illustrate use of new variable.
(STRING= (SYMBOL-NAME (LET ((*GENSYM-COUNTER* 43)) (GENSYM "FOO")))
"FOO43")
=> T ;under this proposal (not meaningful previously)
Current Practice:
Symbolics Cloe and Genera are compatible with CLtL, so this would be an
incompatible change.
Cost to Implementors:
Very small.
If any implementations currently use a more compact representation for
the internal state of GENSYM than a variable holding a string and a
separate variable holding an integer, they might be forced to change.
Even then, the change would proabably still be quite small.
Cost to Users:
Most uses of GENSYM do not depend on the stickiness of the name, so the
change would be compatible. In some cases, the change would be an
improvement. Even in the worst case where someone depends on stickiness,
it's extremely straightforward to write the couple of lines of code to
produce an application based on MAKE-SYMBOL that is at least as flexible
as GENSYM, and often moreso.
Cost of Non-Adoption:
Good programmers would avoid using the argument to GENSYM (or using
GENSYM altogether) in many situations where they ought not have to.
Benefits:
Gensyms which appear to convey information through their name would not
accidentally pop out and cause confusion in places where they oughtn't.
Making the gensym counter visible as a variable means that people will
be able to bind the gensym counter locally when they don't want to affect
the global counter.
Aesthetics:
Unnecessary global state changes are hard to reason about. This would
be a small simplification.
Discussion:
Pitman claims to have written a non-sticky GENSYM function for nearly
every one of the dozen or so large systems that he's written or worked
on in the last decade in order to get around the stated problem.
Others have suggested similar experience.
Pitman and Steele support LIKE-TEFLON.
∂21-Mar-89 1503 CL-Cleanup-mailer New cleanup issues
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Mar 89 15:02:53 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 562318; Tue 21-Mar-89 18:01:47 EST
Date: Tue, 21 Mar 89 18:01 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: New cleanup issues
To: Masinter.pa@XEROX.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <19890321230141.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Since you were on travel, I took the liberty of mailing a few
additional issues to X3J13. I'll bring at least one copy of
these to the meeting, and I hope if there is time we can discuss
them and vote to get them out of the way. None should be controversial.
∂21-Mar-89 1601 CL-Cleanup-mailer New issue: WITH-OPEN-FILE-DOES-NOT-EXIST
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Mar 89 16:01:17 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 562394; Tue 21-Mar-89 18:59:52 EST
Date: Tue, 21 Mar 89 18:59 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: New issue: WITH-OPEN-FILE-DOES-NOT-EXIST
To: peck@Sun.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8903180525.AA21223@denali.sun.com>
Message-ID: <19890321235935.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I think WITH-OPEN-FILE-DOES-NOT-EXIST:STREAM-IS-NIL is clearly correct,
although I agree that CLtL doesn't really say.
∂21-Mar-89 1643 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-VALUE (version 1)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 21 Mar 89 16:43:10 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Tue, 21 Mar 89 19:20:00 EST
Date: Tue, 21 Mar 89 19:21 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: PATHNAME-COMPONENT-VALUE (version 1)
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <19890321225242.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <19890322002110.7.BARMAR@OCCAM.THINK.COM>
This is all well and good, but it doesn't address the BIGGEST obstacle
to portable use of MAKE-PATHNAME: uppercase vs lowercase. If I can't
write something as simple as
(setq dp (pathname "/u/barmar/foo.lisp"))
(namestring (make-pathname :name "bar" :defaults dp))
and have it mean the same thing in Lucid and Genera, what good is all
the rest? Anyone trying to deal with pathnames portably needs to write
a set of wrapper functions, as Thinking Machines has. Your proposals
don't really make this much easier.
The only effect of the various pathname proposals is to extend the
standard so that Symbolics's implementation conforms. I have no problem
with this goal, but I think the approach is wrong. What's the point of
rules 1-8, which specify the data types that the pathname accessors may
return, but don't specify the semantics of the values? If we're not
going to specify all the semantics, we might as well just say that they
can return any type, since there's nothing that a portable program can
do besides stick the values in another pathname. I think the only
useful rules in the whole list are 11 (any component can be NIL), 12
(any component can be :WILD), 15 (the version can be :NEWEST), and 16
(any component may be copied to the corresponding component of another
pathname on the same (EQL? EQUAL?) host and device). Rule 13 (most
components can be strings) is not useful because it doesn't define the
relationship between the string specified and the name of the file that
will be accessed (CLtL doesn't say whether (make-pathname :name "FOO")
accesses a file named "FOO", "foo", or "BAR").
Background:
For those of you not familiar with Genera's mechanism for dealing with
pathname case (with which I can't really find fault, because it is the
only way to solve problem of name translation across OS types, but it
does result in portability problems), the above sequence results in
"/u/barmar/BAR.lisp" in Genera, but "/u/barmar/bar.lisp" in most Unix
implementations. In Genera, the string arguments to MAKE-PATHNAME, and
the results of the PATHNAME-<component> functions, are not necessarily
in the same case the actual pathname, but in a format called
"interchange case". In interchange format, uppercase represents the
preferred case for the OS, lowercase represents the opposite case, and
mixed case is used verbatim. This allows you to do
(make-pathname :name (pathname-name <unix-path>) :defaults <vms-path>)
and have the lowercase Unix name translated to an uppercase VMS name
automatically.
Unfortunately, I can't think of any way to solve this problem in the
standard without incorporating the whole concept of interchange case
into it. There might not be too much opposition to it if we change the
design so that lowercase were used to represent the preferred case,
though. How many uppercase-preferred systems are used much for Common
Lisp? Are there any besides VAX/VMS? (Uppercase-only systems such as
MS-DOS and case-insensitive systems such as Macintosh don't count, since
they can use uppercase or lowercase interchangeably without affecting
the semantics.)
By the way, there should probably be a rule somewhere that says that
portable programs shouldn't expect to be able to create and/or access
distinct files whose pathname components differ only in case.
∂21-Mar-89 1752 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-VALUE (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Mar 89 17:52:34 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 562499; Tue 21-Mar-89 20:49:08 EST
Date: Tue, 21 Mar 89 20:48 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-COMPONENT-VALUE (version 1)
To: Barry Margolin <barmar@Think.COM>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19890322002110.7.BARMAR@OCCAM.THINK.COM>
Message-ID: <19890322014857.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 21 Mar 89 19:21 EST
From: Barry Margolin <barmar@Think.COM>
This is all well and good, but it doesn't address the BIGGEST obstacle
to portable use of MAKE-PATHNAME: uppercase vs lowercase.
PATHNAME-COMPONENT-CASE addresses that; it's a separate issue. I don't
know whether it's on the agenda for next week, but I hope it is.
The only effect of the various pathname proposals is to extend the
standard so that Symbolics's implementation conforms.
Well, I certainly hope that with all the pathname proposals together,
that is not the only effect! The goal is to constrain the semantics
of pathnames enough to allow writing portable pathname-using programs,
so people will stop complaining that pathnames are a useless wart.
Maybe it was wrong to break it up into separate issues.
I have no problem
with this goal, but I think the approach is wrong. What's the point of
rules 1-8, which specify the data types that the pathname accessors may
return, but don't specify the semantics of the values? If we're not
going to specify all the semantics, we might as well just say that they
can return any type, since there's nothing that a portable program can
do besides stick the values in another pathname. I think the only
useful rules in the whole list are 11 (any component can be NIL), 12
(any component can be :WILD), 15 (the version can be :NEWEST), and 16
(any component may be copied to the corresponding component of another
pathname on the same (EQL? EQUAL?) host and device). Rule 13 (most
components can be strings) is not useful because it doesn't define the
relationship between the string specified and the name of the file that
will be accessed (CLtL doesn't say whether (make-pathname :name "FOO")
accesses a file named "FOO", "foo", or "BAR").
I think you're partly right here. It was probably a mistake to try to
constrain the types of "structured" values, because there is nothing
that a portable program can do with a "structured" value that depends on
the type.
As for strings, the intent was that with PATHNAME-COMPONENT-CASE the
relation between the string and the name of the file is fully specified;
I guess that wasn't at all clear from the PATHNAME-COMPONENT-VALUE
writeup. Similarly, with PATHNAME-SUBDIRECTORY-LIST the relation
between the list and the name of the directory is fully specified.
I see the proposal for PATHNAME-COMPONENT-CASE is rather stale, I'll
see if I can work up a version updated from the discussion tonight or
tomorrow.
By the way, there should probably be a rule somewhere that says that
portable programs shouldn't expect to be able to create and/or access
distinct files whose pathname components differ only in case.
Good point.
∂21-Mar-89 2227 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-VALUE (version 1)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 21 Mar 89 22:27:46 PST
Return-Path: <barmar@Think.COM>
Received: from kulla.think.com by Think.COM; Wed, 22 Mar 89 00:54:22 EST
Received: by kulla.think.com; Wed, 22 Mar 89 00:54:37 EST
Date: Wed, 22 Mar 89 00:54:37 EST
From: barmar@Think.COM
Message-Id: <8903220554.AA25095@kulla.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 21 Mar 89 20:48 EST <19890322014857.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-COMPONENT-VALUE (version 1)
Not being on cl-cleanup, I wasn't aware of PATHNAME-COMPONENT-CASE.
You may be right that it was wrong to break up the issues. On the
other hand, merging them all together would probably result in a
2K-line issue, which is no fun, either.
barmar
∂22-Mar-89 1054 CL-Cleanup-mailer PRETTY-PRINT-INTERFACE, version 4
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Mar 89 10:54:13 PST
Received: from wheat-chex.ai.mit.edu by life.ai.mit.edu; Wed, 22 Mar 89 13:54:36 EST
Received: from localhost by wheat-chex.ai.mit.edu; Wed, 22 Mar 89 13:54:34 EST
Date: Wed, 22 Mar 89 13:54:34 EST
From: dick@wheaties.ai.mit.edu
Message-Id: <8903221854.AA10669@wheat-chex.ai.mit.edu>
To: cl-cleanup@sail.stanford.edu
Subject: PRETTY-PRINT-INTERFACE, version 4
Version 3 (by Guy Steele Jr) supersedes version 2 and is changed from
version 1 as follows: adds a functional interface to supplement the
interface through FORMAT, and reflects comments by Barrett and
Pierson.
Version 4 (by Dick Waters) is changed from version 3 as follows: The
short summary is updated to reflect the functional interface. The
functional interface is changed following suggestions made by Dave Moon.
The proposal is amended in a few minor ways to increase the
compatibility with variable width fonts. Additional discussion has been
added with regard to the advantages of XP with regard to handling
circularity detection and abbreviation, the interaction with CLOS, and
the extended type specifier CONS used by XP.
The document attached to version 1 has also been fully revised, but is
sent in a separate message due to mailer problems.
--Dick
Issue: PRETTY-PRINT-INTERFACE
References: Description of XP by Dick Waters (attached)
*PRINT-PRETTY* (CLtL p. 371)
WRITE (CLtL p. 382)
PPRINT (CLtL p. 383)
FORMAT (CLtL pp. 385-407)
FORMAT ~T directive (CLtL pp. 398-399)
FORMAT ~< directive (CLtL pp. 404-406)
Related issues:
Category: CLARIFICATION CHANGE ADDITION
Edit history: Version 1, 24-Feb-89 by Steele
Version 2, 15-Mar-89 by Steele and Waters
Version 3, 15-Mar-89 by Steele
Version 4, 22-Mar-89 by Waters
Problem description:
At present, Common Lisp provides no specification whatsoever of how
pretty-printing is to be accomplished, and no way for the user to control
it. In particular, there is no protocol by which a user can write a
print-function for a structure, or a method for PRINT-OBJECT, that will
interact smoothly with the built-in pretty-printer in a portable manner.
Proposal (PRETTY-PRINT-INTERFACE:XP):
Adopt the interfaces and protocols of the XP pretty-printer by Dick Waters,
described in full in the attached 12-page document. Here is a very brief
summary of the proposal.
New variables: *PRINT-DISPATCH*
*PRINT-RIGHT-MARGIN*
*DEFAULT-RIGHT-MARGIN*
*PRINT-MISER-WIDTH*
*PRINT-LINES*
*LAST-ABBREVIATED-PRINTING*
New functions: COPY-PRINT-DISPATCH
FILL-STYLE
LINEAR-STYLE
TABULAR-STYLE
CONDITIONAL-NEWLINE
LOGICAL-BLOCK-TAB
LOGICAL-BLOCK-INDENT
New macros: DEFINE-PRINT-DISPATCH
WITHIN-LOGICAL-BLOCK
LOGICAL-BLOCK-COUNT
LOGICAL-BLOCK-POP
New FORMAT directives: ~W ~_ ~I ~:T ~/name/ ~<...~:>
New # reader macro: #"..."
The function WRITE is extended to accept additional keyword arguments
:DISPATCH, :RIGHT-MARGIN, :LINES, and :MISER-WIDTH corresponding to the
first four of the new variables.
Examples: See attached document.
Rationale:
There ought to be a good user interface to the pretty printer.
This is the only proposal for which there is a portable implementation
that has seen extensive use and is being made freely available.
Current practice:
XP son of PP son of GPRINT son of PRINT* is the latest in a line of pretty
printers that goes back 13 years. All of these printers use essentially
the same basic algorithm and conceptual interface. Further, except for
PRINT*, which was implemented solely to satisfy the author's personal
needs, each of these printers has had extensive use. XP has been in
experimental use as the pretty printer in CMU Common Lisp for 6 months. PP
has been the pretty printer in DEC Common Lisp for the past 3 years. Prior
to three years ago, GPRINT was used for 2 years as the pretty printer in
DEC Common Lisp. In addition, GPRINT has been the pretty printer in
various generations of Symbolics Lisp for upwards of 5 years.
(See Waters R.C., "User Format Control in a Lisp Prettyprinter", ACM TOPLAS,
5(4):513--531, October 1983.)
Cost to Implementors:
A fair amount of effort (perhaps a few man-weeks at most).
Source code for XP is available to all comers from Dick Waters, and
the system is documented in great detail:
Waters, Richard C., "XP: A Common Lisp Pretty Printing System",
Artificial Intelligence Laboratory Technical Memo 1102,
Massachusetts Institute of Technology, Cambridge MA, March 1989.
Cost to Users: None (I think). This is an upward-compatible extension.
Cost of non-adoption: Continued inability for user print-functions
to interact with the pretty-printer in a useful and portable manner.
Performance impact: XP is claimed to be quite fast.
Benefits: User control of pretty-printing in a portable manner.
Aesthetics:
Using ~<...~:> may strike some as uncomfortably close in the syntactic
space of FORMAT directives to the existing ~<...~>. However, it is very
unlikely that both of these directives (pretty-print logical block and
columnar justification, respectively) will be used in the same call to
FORMAT. Previous versions of XP used ~!...~. instead of ~<...~:> but this
made FORMAT strings very difficult to read; it is preferable to have
a directive that looks like matching brackets of some sort.
Dan Pierson comments: You might mention that some people will undoubtedly
find piling more hair on FORMAT ugly (of course these same people may
well find FORMAT in general ugly :-)).
Discussion:
Zetalisp used ~:T to mean pixelwise tabulation, so the use of ~:T
suggested here may be a problem. If so, another suggestion for naming
this directive would be appropriate.
The ~/.../ directive is already in Zetalisp, and is not an idea new
to this proposal. However, it should be noted that the proposal for
~/.../ here is simpler than, and incompatible with, the current Zatalisp
practice.
Guy Steele and Dick Waters strongly support this proposal. (As an example,
Guy Steele has a portable simulator for Connection Machine Lisp, and would
like very much to have xappings and xectors pretty-print properly.)
Dan Pierson comments: You can add me to the list of strong supporters of
this proposal. While the proposal is long and complex, it is supported by
a long history of usage in several different Lisp environments. Unlike
some earlier members of this family, this version fits cleanly enough into
the rest of Common Lisp to warrant standardization.
The utility of *PRINT-LINES* becomes more obvious if it is pointed out
that Dick's pretty printers are implemented to print each line as it
is computed. This means that a small value for *PRINT-LINES* saves
significant time as well as output medium space. In fact, many people
find that a very pleasant REP loop is created by setting *PRINT-LINES*
to a value from 1-4, *PRINT-PRETTY* to T, and defining a short-name
function (say (PP*)) that funcalls *LAST-ABBREVIATED-PRINTING* with
abbreviation bound off. This is almost as fast and compact as, and
MUCH more readable than, a non-pretty-printing REP loop.
The advantages of compiled format strings (format functions) should be
brought out as benefits in their own right. The current proposal just
mentions them as a minor feature of XP.
At first this struck me a very cute end run around the failure of
STREAM-INFO, then I realized that one of the problems with STREAM-INFO
may have been that it was a standard at the wrong level. STREAM-INFO
permitted people to use XP, but not to count on it. This proposal
makes it possible to write portable code whose new data structures and
language elements print correctly in whatever Common Lisp environment
they're run in. [End of comments by Pierson]
It has been noted by Guy Steele that some places in the initial document
where it says that circularity detection is handled correctly, this is
true a fortiori following the decision on PRINT-CIRCLE-STRUCTURE.
However, Waters notes that the vote on PRINT-CIRCLE-STRUCTURE said
nothing about the handling of *PRINT-LEVEL*. Therefore, the fact that
XP handles *PRINT-LEVEL* correctly is an improvement.
In addition, PRINT-CIRCLE-STRUCTURE is also silent on what is supposed
to happen if a user program decomposes a list itself (e.g., with DOLIST
or ~{~}) rather than calling a print function. Assumedly *PRINT-CIRCLE*
etc. is not handled in this case. In contrast, if one uses
WITHIN-LOGICAL-BLOCK or ~<~:>, then *PRINT-CIRCLE*, *PRINT-LEVEL*, and
*PRINT-LENGTH* are all automatically handled correctly.
For example, (format nil "-~1{~A ~A ~A ~A ~A ~}-" '#1=(1 #1# 2 . #1#))?
produces "-1 #1=(1 #1# 2 . #1#) 2 1 #1=(1 #1# 2 . #1#) -"
even under PRINT-CIRCLE-STRUCTURE and
(format nil "-~1{~A ~}-" '#1=(1 #1# 2 . #1#))
cause infinite looping. However, in XP,
(format nil "-~:<~W ~W ~W ~W ~W~:>-" '#1=(1 #1# 2 . #1#))
produces "-#1=(1 #1# 2 . #1#)-".
This proves to be very useful when writing pretty printing functions for things.
Note also that ~<~:> supports *print-level* and *print-length* correctly.
All the same things can be said about the functional interface and using
WITHIN-LOGICAL-BLOCK rather than traversing a list yourself in some fashion.
All in all, Waters claims that PRINT-CIRCLE-STRUCTURE covers at most 1/4
of what XP does in support of *print-circle* and does not cover anything
of what XP does to support *print-level*, *print-length*, and
robustness in the face of malformed arguments. These are vital
features for writing printing functions that really work right all the time.
It has been noted by Dave Moon that things would be much more elegant if
DEFINE-PRINT-DISPATCH could be expressed directly as a CLOS DEFMETHOD
for an appropriate generic function. Dick Waters agrees with this.
However, DEFINE-PRINT-DISPATCH depends on type specifiers that are more
complex than the ones CLOS deals with and ones that do not have clear
subtype/supertype relationships, compensating for the latter problem by
supporting numerical priorities to disambiguate things. (The defaulting
behavior is a key feature of the pretty printer.) At the very least,
this means that DEFINE-PRINT-DISPATCH will not fit into CLOS in a simple way.
Given the problems, Moon suggests that "it does seem that right now it
might be best to keep a separate DEFINE-PRINT-DISPATCH macro, with the
idea that the expansion is implementation-dependent at the moment, but
might some day be changed to be defined to expand into DEFMETHOD. I
haven't looked to see whether any syntactic changes would be appropriate
to make that transition smoother."
(Waters also worries that the overhead needed to locate the right CLOS
method would seriously degrade the pretty printer, because the printer
has to do this for every part of every object printed. This dispatching is
currently done by very fast code that is tuned to take advantage of the
observed distribution of kinds of objects that have special pretty
printers attached to them. Even with this special purpose code,
dispatching takes a significant part of the pretty printer's time.)
Dave Moon also comments that it is not good to have something that looks
like a type specifier (i.e., the extended form of the CONS type specifier
used by DEFINE-PRINT-DISPATCH) and yet is not a real type specifier. He
suggests that we should either amend Common Lisp to accept the extended
form of the CONS type specifier, or stop having DEFINE-PRINT-DISPATCH
use it.
Waters supports any course of action that retains the use of the
extended CONS type specifier in conjunction with DEFINE-PRINT-DISPATCH.
However, he notes that the trade-off is clear. One could avoid the
complex CONS type specifier without any significant loss of
functionality by introducing a new macro DEFINE-LIST-PRINT-DISPATCH that
is identical to DEFINE-PRINT-DISPATCH except that it is relevant only to
conses and the type specifier applies to the CAR of the object to be
printed rather than to the object as a whole. However, this appears to
him to be significantly less elegant than the current approach.
-------------------- detailed documentation --------------------
The full description is too large to fit in with everything else in this
message. A fully correct version follows in a separate message. The
stuff below summarizes all of the changes from the full description in
version 1.
Amendments
To a considerable extent, the design of the XP interface is completely
neutral about the issue of variable- versus fixed- width fonts. In
particular, most of the discussion of how the formating proceeds either
talks about absolute positions of zero or talks about something being
in the same horizontal position as something else. These statements are
all font-independent. (Further, although Waters' current implementation
does not support variable-width fonts, the algorithms used could be
extended to support them without radical changes.)
Nevertheless, there are 9 places where users specify explicit
non-zero lengths: the variables *PRINT-RIGHT-MARGIN*,
*DEFAULT-RIGHT-MARGIN*, and *PRINT-MISER-WIDTH*, the numeric
arguments to ~T, ~I, and ~/tabular-style/ and their associated functions
LOGICAL-BLOCK-TAB, LOGICAL-BLOCK-INDENT, and TABULAR-STYLE.
It is proposed that all of these lengths be in the same units, and that
this unit be ems (the length of an "m" in the font currently being used
to output characters to the relevant output stream at the moment that
the command is encountered or a variable is consulted).
It is further proposed that users and implementors be advised to set
things up so that explicit lengths do not have to be specified. For
implementors, this means making streams smart enough that they know how
wide they are. (This avoids the use of *PRINT-RIGHT-MARGIN* and
*DEFAULT-RIGHT-MARGIN* in most situations.) For users, this means
relying on streams knowing their own widths (which is a good idea for
adaptability in any case) and using ~:I to specify indentations wherever
possible. Further, it should be noted that since *PRINT-MISER-WIDTH* is
essentially heuristic in nature, it does not matter if its value is only
an approximate length and users will only need to change the
value of *PRINT-MISER-WIDTH* in unusual situations. This leaves only
tabbing as an area where explicit lengths have to be specified on a
regular basis. Fortunately, approximate lengths are often acceptable in
this situation as well.
Functional Interface
The primary interface to operations for dynamically determining the
arrangement of output is provided through FORMAT. This is done,
because FORMAT strings are typically the most convenient way of
interacting with pretty printing. However, these operations have
nothing inherently to do with FORMAT per se. In particular, they can
also be accessed via the six functions and macros below.
WITHIN-LOGICAL-BLOCK (STREAM-SYMBOL LIST [Macro]
:PREFIX :PER-LINE-PREFIX :SUFFIX)
&BODY BODY
In the manner of ~<...~:>, this macro causes printing to be
grouped into a logical block. The value NIL is always returned.
STREAM-SYMBOL must be a symbol. If it is NIL, it is treated the same as
if it were *STANDARD-OUTPUT*. If it is T, it is treated the same as if
it were *TERMINAL-IO*. The run-time value of STREAM-SYMBOL must be a
stream. The logical block is printed into this destination stream.
The BODY can contain any arbitrary Lisp forms. Within the BODY,
STREAM-SYMBOL is bound to a special kind of stream that supports dynamic
decisions about the arrangement of output and then forwards the output
to the destination stream. All the standard printing functions (e.g.,
WRITE, PRINC, TERPRI) can be used to print output into STREAM-SYMBOL.
All and only the output sent to STREAM-SYMBOL is treated as being in the
logical block. (It is an error to send any output directly to the
underlying destination stream.)
The :SUFFIX, :PREFIX, and :PER-LINE-PREFIX must all be expressions that
(at run time) evaluate to strings. :SUFFIX (which defaults to the null
string) specifies a suffix that is printed just after the logical block.
:PREFIX specifies a prefix to be printed before the beginning of the
logical block. :PER-LINE-PREFIX specifies a prefix that is printed
before the block and at the beginning of each new line in the block. It
is an error for :PREFIX and :PRE-LINE-PREFIX to both be used. If neither
is used, a :PREFIX of the null string is assumed.
LIST is interpreted as being a list that BODY is responsible for
printing. If LIST does not (at run time) evaluate to a list, it is
printed using WRITE. If *PRINT-CIRCLE* is not NIL and LIST is a
circular reference to a cons, then an appropriate #n# marker is printed.
If *PRINT-LEVEL* is not NIL and the logical block is at a dynamic
nesting depth of greater than *PRINT-LEVEL* in logical blocks, # is
printed. If either of the three conditions above occures, the indicated
special output is printed on STREAM-SYMBOL and the BODY is skipped along
with the printing of the prefix and suffix. (If the BODY is
not responsible for printing a list, then the first two tests above can
be turned off by supplying NIL for the LIST argument.)
CONDITIONAL-NEWLINE KIND &OPTIONAL (STREAM *STANDARD-OUTPUT*) [Function]
CONDITIONAL-NEWLINE is the functional equivalent of ~_. STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions (i.e., NIL stands for
*STANDARD-OUTPUT* and T stands for *TERMINAL-IO*). The KIND argument
specifies the style of conditional newline. It must be one of :LINEAR,
:FILL, :MISER, or :MANDATORY. If STREAM is a special stream bound by
WITHIN-LOGICAL-BLOCK, a conditional newline is sent to it. Otherwise,
CONDITIONAL-NEWLINE has no effect. The value NIL is always returned.
LOGICAL-BLOCK-INDENT RELATIVE-TO N &OPTIONAL (STREAM *STANDARD-OUTPUT*) [Function]
LOGICAL-BLOCK-INDENT is the functional equivalent of ~I. STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions. N specifies the indentation in
ems. If RELATIVE-TO is :BLOCK, this indentation is relative to the
start of the enclosing block (as for ~I). If RELATIVE-TO is :CURRENT,
the indentation is relative to the current output position (as for ~:I).
It is an error for RELATIVE-TO to take on any other value. If STREAM is
a special stream bound by WITHIN-LOGICAL-BLOCK, LOGICAL-BLOCK-INDENT
sets the indentation in the innermost enclosing logical block.
Otherwise, LOGICAL-BLOCK-INDENT has no effect. The value NIL is always
returned.
LOGICAL-BLOCK-TAB KIND COLNUM COLINC &OPTIONAL (STREAM *STANDARD-OUTPUT*)
LOGICAL-BLOCK-TAB is the functional equivalent of ~T. STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions. The arguments COLNUM and COLINC
correspond to the two numeric parameters to ~T and are in terms of ems.
The KIND argument specifies the style of tabbing. It must be one of
:LINE (tab using ~T), :BLOCK (tab using ~:T), :LINE-RELATIVE (tab using
~@T), or :BLOCK-RELATIVE (tab using ~:@T). If STREAM is a special
stream bound by WITHIN-LOGICAL-BLOCK, tabbing is performed. Otherwise,
LOGICAL-BLOCK-TAB has no effect. The value NIL is always returned.
LOGICAL-BLOCK-POP ARGS &OPTIONAL (STREAM *STANDARD-OUTPUT*) [Macro]
LOGICAL-BLOCK-COUNT &OPTIONAL (STREAM *STANDARD-OUTPUT*) [Macro]
LOGICAL-BLOCK-POP is identical to POP except that it supports
*PRINT-LENGTH* and *PRINT-CIRCLE*. It is an error to use
LOGICAL-BLOCK-POP anywhere other than syntactically nested within a
call on WITHIN-LOGICAL-BLOCK.
ARGS must be a symbol or expression acceptable to POP. STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions. If STREAM is a special stream
bound by WITHIN-LOGICAL-BLOCK, then LOGICAL-BLOCK-POP performs the
special operations described below. Otherwise, LOGICAL-BLOCK-POP is
identical to POP.
Each time LOGICAL-BLOCK-POP is called, it performs three tests. if
ARGS is not a cons, ". " is printed followed by ARGS. If
*PRINT-LENGTH* is NIL and LOGICAL-BLOCK-POP has already been called
*PRINT-LENGTH* times within the immediately containing logical block,
"..." is printed. If *PRINT-CIRCLE* is not NIL, and ARGS is a circular
reference, then ". " is printed followed by an appropriate #n# marker.
If either of the three conditions above occurs, the special output is
printed on :STREAM and the execution of the immediately containing
WITHIN-LOGICAL-BLOCK is terminated except for the printing of the
suffix. Otherwise, LOGICAL-BLOCK-POP pops the top value off of ARGS
and returns this value.
LOGICAL-BLOCK-COUNT is identical to LOGICAL-BLOCK-POP except that it
does not take an ARGS argument, always returns NIL, and only performs
the second test discussed above. It is useful when the components of a
non-list are being printed.
Using the functions above, TABULAR-STYLE could be defined as follows.
(defun tabular-style (s list &optional (colon? T) atsign? (tabsize nil))
(declare (ignore atsign?))
(if (null tabsize) (setq tabsize 16))
(within-logical-block (s list :prefix (if colon? "(" "")
:suffix (if colon? ")" ""))
(when list
(loop (write (logical-block-pop list s) :stream s)
(if (null list) (return nil))
(write-char #\space s)
(logical-block-tab :block-relative 0 tabsize s)
(conditional-newline :fill s)))))
The function below prints a vector using #(...) notation.
(defun print-vector (v *standard-output*)
(within-logical-block (nil nil :prefix "#(" :suffix ")")
(let ((end (length v)) (i 0))
(when (plusp end)
(loop (logical-block-count)
(write (aref v i))
(if (= (incf i) end) (return nil))
(write-char #\space)
(conditional-newline :fill))))))
FILL-STYLE STREAM LIST &OPTIONAL (COLON? T) ATSIGN?
LINEAR-STYLE STREAM LIST &OPTIONAL (COLON? T) ATSIGN?
TABULAR-STYLE STREAM LIST &OPTIONAL (COLON? T) ATSIGN? (TABSIZE 16)
The directives ~/fill-style/, ~/linear-style/, and ~/tabular-style/ are
supported by the three functions above. These functions can also be
called directly by the user. Each function prints parentheses around
the output if an only if COLON? (default T) is not NIL. Each function
ignores its ATSIGN? argument and returns NIL. (These arguments are
optional to facilitate the direct use of the three functions.) Each
function handles abbreviation and circularity detection correctly, and
uses WRITE to print LIST when given a non-list argument.
The function LINEAR-STYLE prints a list either all on one line, or with
each element on a separate line. The function FILL-STYLE prints a list
with as many elements as possible on each line. The function
TABULAR-STYLE is the same as FILL-STYLE except that it prints the
elements so that they line up in columns. This function takes an
additional argument TABSIZE (default 16) that specifies the column
spacing in ems.
[End of attached document]
∂22-Mar-89 1057 CL-Cleanup-mailer PRETTY-PRINT-INTERFACE, version 4
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Mar 89 10:56:27 PST
Received: from wheat-chex.ai.mit.edu by life.ai.mit.edu; Wed, 22 Mar 89 13:56:35 EST
Received: from localhost by wheat-chex.ai.mit.edu; Wed, 22 Mar 89 13:56:33 EST
Date: Wed, 22 Mar 89 13:56:33 EST
From: dick@wheaties.ai.mit.edu
Message-Id: <8903221856.AA10674@wheat-chex.ai.mit.edu>
To: cl-cleanup@sail.stanford.edu
Subject: PRETTY-PRINT-INTERFACE, version 4
Issue: PRETTY-PRINT-INTERFACE
Full description of XP accompanying version 4 of the proposal
--------------------
Pretty Printing
Richard C. Waters
Pretty printing has traditionally been a black box process, displaying
program code using a set of fixed layout rules. Its utility can be greatly
enhanced by opening it up to user control.
By providing direct access to the mechanisms within the pretty printer that
make dynamic decisions about layout, the FORMAT directives ~_, ~I, and
~<...~:> make it possible to specify pretty printing layout rules as a part
of any function that produces output. They also make it very easy for
circularity detection and abbreviation based on length and nesting depth to
be supported by the function. The construct DEFINE-PRINT-DISPATCH makes it
possible to associate a user-defined pretty printing function with any type
of object. Together, these facilities enable users to redefine the way
code is displayed and allow the full power of pretty printing to be applied
to complex combinations of data structures.
Pretty Printing Control Variables
*PRINT-DISPATCH* [variable]
When *PRINT-PRETTY* is not NIL, the print dispatch table in
*PRINT-DISPATCH* controls the way objects are printed. The initial value
of *PRINT-DISPATCH* causes traditional pretty printing of Lisp code.
*PRINT-RIGHT-MARGIN* [variable]
*DEFAULT-RIGHT-MARGIN* [variable]
The goal of dynamic layout decisions (when pretty printing or when directly
specified via ~_, ~I, and ~<...~:>) is to keep the output between a pair of
margins. The left margin is set at the column where the output begins. If
this cannot be determined, the left margin is set to zero.
When *PRINT-RIGHT-MARGIN* is not NIL, it specifies the right margin to use
when making layout decisions. When *PRINT-RIGHT-MARGIN* is NIL (the
initial value), the right margin is set at the maximum line length that can
be displayed by the output stream without wraparound or truncation. If
this cannot be determined, the right margin is set to
*DEFAULT-RIGHT-MARGIN*. The initial value of *DEFAULT-RIGHT-MARGIN* is
implementation-dependent.
To allow for the possibility of variable-width fonts, both of these
variables are interpreted in terms of ems---the length of an "m"
in the font being used to display characters on the relevant output
stream at the moment when the variables are consulted.
*PRINT-MISER-WIDTH* [variable]
If *PRINT-MISER-WIDTH* is not NIL, the pretty printer switches to a compact
style of output (called miser style) whenever the width available for
printing a substructure is less than or equal to *PRINT-MISER-WIDTH* ems. The
initial value of *PRINT-MISER-WIDTH* is implementation-dependent.
!
*PRINT-LINES* [variable]
When given a value other than its initial value of NIL, *PRINT-LINES*
limits the number of output lines produced when something is printed. If
an attempt is made to go beyond *PRINT-LINES* lines, " ---" is printed at
the end of the last line and printing stops.
(let ((*print-right-margin* 20) (*print-lines* 3))
(pprint '(setq a 1 b 2 c 3 d 4)))
(SETQ A 1
B 2
C 3 ---
*LAST-ABBREVIATED-PRINTING* [variable]
This variable records the last printing event where abbreviation occurred.
Funcalling its value (e.g., after turning off abbreviation) causes the
printing to happen a second time.
The function WRITE accepts keyword arguments :DISPATCH, :RIGHT-MARGIN,
:LINES, and :MISER-WIDTH corresponding to *PRINT-DISPATCH*,
*PRINT-RIGHT-MARGIN*, *PRINT-LINES*, and *PRINT-MISER-WIDTH*.
Compiling Format Control Strings
The control strings used by FORMAT are essentially programs that perform
printing. The readmacro character #"..." provides the efficiency of using
a compiled function for printing without losing the conciseness of FORMAT
control strings. In the notation #"...", the string following # is
identical to a FORMAT control string. However, the readmacro translates it
into an equivalent sharp-quoted function. The first expression below is
equivalent to the second.
#"~%~@{~S~↑, ~}"
#'(lambda (stream &rest args)
(terpri stream)
(loop (prin1 (pop args) stream)
(if (null args) (return nil))
(write-string ", " stream)))
In support of the above, FORMAT accepts functions as its second argument as
well as strings. When a function is provided, it is called with the
appropriate output stream as its first argument and the data arguments to
FORMAT as its remaining arguments. The function should perform whatever
output is necessary. The values returned by the function are ignored. The
directive ~? also accepts functions as well as control strings.
!
Dynamic Control of the Arrangement of Output
The following FORMAT directives support precise control of what should be
done when a piece of output is too large to fit in the space available.
Three concepts underlie the way these directives work---`logical blocks',
`conditional newlines', and `sections'.
The first line of Figure 1 shows a schematic piece of output. The
characters in the output are represented by "-". The positions of
conditional newlines are indicated by digits. The beginnings and ends of
logical blocks are indicated by "<" and ">" respectively.
The output as a whole is a logical block and the outermost section. This
section is indicated by the 0's on the second line of Figure 1. Logical
blocks nested within the output are specified by ~<...~:> directives.
Conditional newline positions are specified by ~_ directives. Each
conditional newline defines two sections (one before it and one after it)
and is associated with a third (the section immediately containing it).
The section after a conditional newline consists of: all the output up to,
but not including, (a) the next conditional newline immediately contained
in the same logical block; or if (a) is not applicable, (b) the next
newline that is at a lesser level of nesting in logical blocks; or if (b)
is not applicable, (c) the end of the output.
The section before a conditional newline consists of: all the output back
to, but not including, (a) the previous conditional newline that is
immediately contained in the same logical block; or if (a) is not
applicable, (b) the beginning of the immediately containing logical block.
The last four lines in Figure 1 indicate the sections before and after the
four conditional newlines.
The section immediately containing a conditional newline is the shortest
section that contains the conditional newline in question. In Figure 1,
the first conditional newline is immediately contained in the section
marked with 0's, the second and third conditional newlines are immediately
contained in the section before the fourth conditional newline, and the
fourth conditional newline is immediately contained in the section after
the first conditional newline.
<-1---<--<--2---3->--4-->->
000000000000000000000000000
11 111111111111111111111111
22 222
333 3333
44444444444444 44444
Figure 1: Example of logical blocks, conditional newlines, and sections.
Whenever possible, the pretty printer displays the entire contents of a
section on a single line. However, if the section is too long to fit in
the space available, line breaks are inserted at conditional newline
positions within the section.
!
~W [format directive]
WRITE -- An arg, any Lisp object, is printed obeying every printer control
variable (as by WRITE). In addition, ~W interacts correctly with depth
abbreviation, by not resetting the depth counter to zero. ~W does not
accept parameters. If given the colon modifier, ~W binds *PRINT-PRETTY* to
T. If given the atsign modifier, ~W binds *PRINT-LEVEL* and *PRINT-LENGTH*
to NIL.
~W provides automatic support for circularity detection. If *PRINT-CIRCLE*
is T and ~W is applied to an argument that has already been encountered
during the printing process, an appropriate #n# marker is inserted in the
output instead of printing the argument.
Circularity detection is supported by effectively doing the printing twice.
On the first pass, circularities are detected and the actual outputting of
characters is suppressed. On the second pass, the appropriate #n= and #n#
markers are inserted and characters are output.
~_ [format directive]
CONDITIONAL NEWLINE -- Without any modifiers, ~_ specifies a
`linear-style' conditional newline. A line break is inserted if and only
if the immediately containing section cannot be printed on one line. The
effect of this is that line breaks are either inserted at every
linear-style conditional newline in a logical block or at none of them.
~@_ specifies a `miser-style' conditional newline. A line break is
inserted if and only if the immediately containing section cannot be
printed on one line and miser style is in effect in the immediately
containing logical block. The effect of this is that miser-style
conditional newlines act like linear-style conditional newlines, but only
when miser style is in effect. Miser style is in effect for a logical
block if and only if the the starting column of the logical block is less
than or equal to *PRINT-MISER-WIDTH* columns from the right margin.
~:_ specifies a `fill-style' conditional newline. A line break is
inserted if and only if either (a) the following section cannot be printed
on the end of the current line, (b) the preceding section was not printed
on a single line, or (c) the immediately containing section cannot be
printed on one line and miser style is in effect in the immediately
containing logical block. If a logical block is broken up into a number
of subsections by fill-style conditional newlines, the basic effect is
that the logical block is printed with as many subsections as possible on
each line. However, if miser style is in effect, fill-style conditional
newlines act like linear-style conditional newlines.
~:@_ specifies a `mandatory-style' conditional newline. A line break is
always inserted. This implies that none of the containing sections can be
printed on a single line and will therefore trigger the insertion of line
breaks at linear-style conditional newlines in these sections.
When a line break is inserted by any type of conditional newline, any
blanks that immediately precede the conditional newline are omitted from
the output and indentation is introduced at the beginning of the next line.
By default, the indentation causes the following line to begin in the same
column as the first character in the immediately containing logical block.
The indentation can be changed via ~I.
There are a variety of ways unconditional newlines can be introduced into
the output (e.g., via ~% or by printing a string containing a newline
character). As with mandatory conditional newlines, this prevents any of
the containing sections from being printed on one line. In general, when
an unconditional newline is encountered, it is printed out without
suppression of the preceding blanks and without any indentation following
it. However, if a per-line prefix has been specified (see ~<...~:>), this
prefix will always be printed no matter how a newline originates.
!
~<...~:> [format directive]
LOGICAL BLOCK -- If ~:> is used to terminate a ~<...~>, the directive
delimits a logical block. In addition, ~<...~:> descends into the
corresponding FORMAT argument (a list) in the same way as the directive
~1{...~:}. ~↑ can be used to exit from ~<...~:> just as it can be used to
exit from ~{...~}.
The portion of a FORMAT control string enclosed in ~<...~:> can be divided
into segments ~<prefix~;body~;suffix~:> by ~; directives. It is an error
for the enclosed portion to be divided into more than three segments. If
the enclosed portion is divided into only two segments, the suffix defaults
to the null string. If the enclosed portion consists of only a single
segment, both the prefix and the suffix default to the null string. If the
colon modifier is used with ~<...~:>, the prefix and suffix default to "("
and ")" (respectively) instead of to the null string.
The prefix and suffix must both be constant strings. They cannot contain
FORMAT directives. The body can be any arbitrary FORMAT control string.
The prefix is printed out just before the logical block is started and the
suffix is printed out just after the logical block ends. This is done even
when the argument corresponding to ~<...~:> is an empty list.
If ~<...~:> is applied to an argument that is not a list, the directive is
ignored (suppressing the output of the prefix and suffix) and the offending
argument is printed using ~W. This makes it easier to write FORMAT strings
that are robust in the face of malformed arguments.
During the processing of the FORMAT string nested in ~<...~:>, arguments
are taken one by one from the list passed to ~<...~:>. If an attempt is
made to access an argument at a time when the remaining portion of this
argument list is not a cons, then ". " is inserted in the output, ~W is
used to print out the remaining argument list, and the processing of the
logical block is terminated, except for printing the suffix (if any). This
makes it easier to write FORMAT strings that are robust in the face of
malformed argument lists. (Note that ~↑ exits only when the remaining
argument list is NIL.)
~<...~:> provides automatic support for depth abbreviation. If
*PRINT-LEVEL* is not NIL and ~<...~:> is encountered at a dynamic nesting
depth in logical blocks greater than *PRINT-LEVEL*, "#" is inserted in the
output and the ~<...~:> and its associated argument are ignored.
~<...~:> provides automatic support for length abbreviation. If
*PRINT-LENGTH* is not NIL, a count is kept of the number of arguments used
within the ~<...~:>. If this count ever reaches *PRINT-LENGTH*, " ..." is
inserted in the output and the processing of the logical block is
terminated, except for printing the suffix (if any).
~<...~:> also provides automatic support for circularity detection. If
*PRINT-CIRCLE* is T and ~<...~:> (without the atsign modifier) is applied
to a list argument that has already been encountered during the printing
process, an appropriate #n# marker is inserted in the output and the
~<...~:> and its associated argument are ignored.
!
In addition, if an attempt is made to access an argument from the list
passed to ~<...~:>, at a time when the remaining portion of this list has
already been encountered during the printing process, ". #n#" is inserted
in the output and the processing of the logical block is terminated, except
for printing the suffix (if any). This catches instances of CDR
circularity in lists.
For circularity detection to work correctly when printing an object, every
part of the object that is a cons must be printed using ~<...~:> and every
non-cons must be printed using ~W. If some part is printed some other way
(e.g., using ~S), circularities involving this part will be missed.
If the atsign modifier is used with ~<...~:>, the entire remaining argument
list is passed to the directive as its argument. Unlike ~1@{...~} all of
the remaining arguments are always consumed by ~@<...~:>, even if they are
not all used by the FORMAT string nested in the directive.
As an example of the interaction of conditional newlines and logical
blocks, consider the following. The FORMAT string specifies how to pretty
print a LET. The outermost ~:<...~:> decomposes the input and specifies
that parentheses should be printed in the output. The
~:<~@{~:<~@{~W~↑~ _~}~:>~↑ ~:_~}~:> decomposes the list of binding pairs.
Each pair in the list is itself decomposed and printed using
~:<~@{~W~↑ ~_~}~:>. (An iteration is used in this FORMAT string instead of
merely decomposing the pair into two elements so that a malformed pair
containing more than two elements will print readably.) A space and a
fill-style conditional newline are placed after each pair except the last.
The ~@{~↑~_ ~W~} prints out the forms in the body of the LET separated by
spaces and linear-style conditional newlines.
(format T #"~:<~W~↑ ~:<~@{~:<~@{~W~↑ ~_~}~:>~↑ ~:_~}~:>~
~@{~↑~_ ~W~}~:>"
'#1=(let (x (*print-length* (f (g 3)))
(z . 2) (k (car y)))
(setq x (sqrt z)) #1#))
Suppose that *PRINT-PRETTY* is T, *PRINT-LEVEL* is 4, and *PRINT-CIRCLE* is
T. If the line length is greater than or equal to 77, the output produced
by the FORMAT above appears on one line. However, if the line length is
76, line breaks are inserted at the linear-style conditional newlines
separating the forms in the body and the output below is produced. Note
that, the degenerate binding pair X is printed readably even though it
fails to be a list; a depth abbreviation marker is printed in place of
(G 3); the binding pair (Z . 2) is printed readably even though it fails
to be a proper list; and appropriate circularity markers are printed.
#1=(LET (X (*PRINT-LENGTH* (F #)) (Z . 2) (K (CAR Y)))
(SETQ X (SQRT Z))
#1#)
If the line length is reduced to 35, a line break is inserted at one of the
fill-style conditional newlines separating the binding pairs.
#1=(LET (X (*PRINT-PRETTY* (F #))
(Z . 2) (K (CAR Y)))
(SETQ X (SQRT Z))
#1#)
!
Suppose that the line length is further reduced to 22 and *PRINT-LENGTH* is
set to 3. In this situation, line breaks are inserted after both the first
and second binding pairs. In addition, the second binding pair is itself
broken across two lines. Clause (b) of the description of fill-style
conditional newlines prevents the binding pair (Z . 2) from being printed
at the end of the third line. Note that the length abbreviation hides the
circularity from view and therefore the printing of circularity markers
disappears as well.
(LET (X
(*PRINT-LENGTH*
(F #))
(Z . 2) ...)
(SETQ X (SQRT Z))
...)
If ~@; is used to terminate the prefix in ~<...~:>, the prefix is a
`per-line' prefix. A per-line prefix is printed at the beginning of every
line in the logical block, rather than just before the start of the block
as a whole. Each instance of the prefix is lined up below the occurrence
of the prefix on the first line. With a line length of 25, the form below
produces the output shown.
(format T #"~<;;; ~@;Roads ~<= ~@;~W, ~:_~W~:> ~:_ Town ~W~:>"
'((elm cottonwood) boston))
;;; Roads = ELM,
;;; = COTTONWOOD
;;; Town BOSTON
If ~<...~:> is terminated with ~:@>, then a fill-style conditional newline
is automatically inserted after each group of blanks immediately contained
in the body (except for blanks after a ~<newline> directive). This makes
it easy to achieve the equivalent of paragraph filling. With a line length
of 12, the form below produces the output shown.
(format T #"~<~:(~W~) street goes to ~:(~W~).~:@>"
'(main boston))
Main street
goes to
Boston.
To a considerable extent, the basic form of the directive ~<...~> is
incompatible with the dynamic control of the arrangement of output by ~W,
~_, ~<...~:>, ~I, and ~:T. As a result, it is an error for any of these
directives to be nested within ~<...~>. Beyond this, it is also an error
for the ~<...~:;...~> form of ~<...~> to be used at all in conjunction with
any of these directives.
!
~I [format directive]
INDENT -- ~nI specifies that the indentation within the immediately
containing logical block should be set to the column position of the
first character in the block plus n ems. If omitted, n defaults to
zero. The parameter can be negative; however, the total indentation
cannot be moved left of the beginning of the line or left of the end of
the rightmost per-line prefix. ~n:I is exactly the same as ~nI except
that it operates relative to the position in the output of the directive
itself, rather than relative to the first character in the block. (For
robustness in the face of variable-width fonts, it is advisable to use
~:I with a parameter of zero instead of ~I whenever possible.) Changes
in indentation caused by a ~I directive do not take effect until after
the next line break. Consider the following example:
(format T #"~:<~W ~@_~:I~W ~:_~W ~1I~_~W~:>"
'(defun prod (x y) (* x y)))
If the line width available is 15, both the ~:_ and the ~_ are replaced by
line breaks. The ~:I directive before the ~W that prints the function name
causes the argument list to be lined up under the function name. The ~1I
directive before the ~_ specifies that the statement in the body of the
DEFUN should be printed at a relative indentation of 1 in the logical
block.
(DEFUN PROD
(X Y)
(* X Y))
In miser style, all ~I directives are ignored, forcing the lines
corresponding to the logical block to line up under the first character in
the block. If *PRINT-MISER-WIDTH* were greater than or equal to 14 (the
block begins in the second column, after the prefix "(" IS printed), the
example output above would have been as follows.
(DEFUN
PROD
(X Y)
(* X Y))
~:T [format directive]
TABULATE -- If the colon modifier is used with the ~T directive, the
tabbing computation is done relative to the column where the section
immediately containing the directive begins, rather than with respect to
column zero. The numerical parameters are both interpreted as being in
units of ems. Consider the following example. Each street name is
followed by a ~8:T, which ensures that the total width taken up will be
a multiple of 8. With a line width of 25, the output shown is produced.
(format T #"~<Roads ~:I~@_~@{~W~↑~8:T~:_~}~:>"
'(elm main maple center))
Roads ELM MAIN
MAPLE CENTER
!
~/name/ [format directive]
CALL FUNCTION -- User defined functions can be called from within a FORMAT
string by using the directive ~/name/. The colon modifier, the atsign
modifier, and arbitrarily many parameters can be specified with the ~/name/
directive. The name can contain a package prefix, but it cannot contain
"/". If the readmacro #"..." is used, the default package associated with
name will be the value of *PACKAGE* at the moment the #"..." is read. If
an ordinary FORMAT control string is used, the default package will be the
value of *PACKAGE* at the moment the string is processed by FORMAT.
When a ~/name/ directive is encountered, the indicated function is called
with four or more arguments. The first four arguments are: the output
stream, the FORMAT argument corresponding to the directive, the value T if
the colon modifier was used (NIL otherwise), and the value T if the atsign
modifier was used (NIL otherwise). The remaining arguments consist of any
parameters specified with the directive. The function should print the
argument appropriately. Any values returned by the function are ignored.
~/LINEAR-STYLE/ [format directive]
An argument, a list, is printed so that either all of the elements are on
one line or each element is on a separate line. Parentheses are printed
around the list if the colon modifier is specified. As an example of a
function intended to be called from within a FORMAT string, the definition
of LINEAR-STYLE is shown below.
(defun linear-style (stream list &optional (colon? T) atsign?)
(declare (ignore atsign?))
(if colon?
(format stream #"~:<~@{~W~↑ ~_~}~:>" list)
(format stream #"~<~@{~W~↑ ~_~}~:>" list)))
~/FILL-STYLE/ [format directive]
An argument, a list, is printed with as many elements as possible on each
line. Parentheses are printed around the list if the colon modifier is
specified.
~/TABULAR-STYLE/ [format directive]
An argument, a list, is printed in a tabular form with as many elements as
possible on each line. In addition to the colon modifier, which causes
parentheses to be printed, ~/TABULAR-STYLE/ takes a parameter
(default 16) that specifies the width in ems of columns in the table.
!
Functional Interface
The primary interface to operations for dynamically determining the
arrangement of output is provided through FORMAT. This is done,
because FORMAT strings are typically the most convenient way of
interacting with pretty printing. However, these operations have
nothing inherently to do with FORMAT per se. In particular, they can
also be accessed via the six functions and macros below.
WITHIN-LOGICAL-BLOCK (STREAM-SYMBOL LIST [Macro]
:PREFIX :PER-LINE-PREFIX :SUFFIX)
&BODY BODY
In the manner of ~<...~:>, this macro causes printing to be
grouped into a logical block. The value NIL is always returned.
STREAM-SYMBOL must be a symbol. If it is NIL, it is treated the same as
if it were *STANDARD-OUTPUT*. If it is T, it is treated the same as if
it were *TERMINAL-IO*. The run-time value of STREAM-SYMBOL must be a
stream. The logical block is printed into this destination stream.
The BODY can contain any arbitrary Lisp forms. Within the BODY,
STREAM-SYMBOL is bound to a special kind of stream that supports dynamic
decisions about the arrangement of output and then forwards the output
to the destination stream. All the standard printing functions (e.g.,
WRITE, PRINC, TERPRI) can be used to print output into STREAM-SYMBOL.
All and only the output sent to STREAM-SYMBOL is treated as being in the
logical block. (It is an error to send any output directly to the
underlying destination stream.)
The :SUFFIX, :PREFIX, and :PER-LINE-PREFIX must all be expressions that
(at run time) evaluate to strings. :SUFFIX (which defaults to the null
string) specifies a suffix that is printed just after the logical block.
:PREFIX specifies a prefix to be printed before the beginning of the
logical block. :PER-LINE-PREFIX specifies a prefix that is printed
before the block and at the beginning of each new line in the block. It
is an error for :PREFIX and :PRE-LINE-PREFIX to both be used. If neither
is used, a :PREFIX of the null string is assumed.
LIST is interpreted as being a list that BODY is responsible for
printing. If LIST does not (at run time) evaluate to a list, it is
printed using WRITE. If *PRINT-CIRCLE* is not NIL and LIST is a
circular reference to a cons, then an appropriate #n# marker is printed.
If *PRINT-LEVEL* is not NIL and the logical block is at a dynamic
nesting depth of greater than *PRINT-LEVEL* in logical blocks, # is
printed. If either of the three conditions above occures, the indicated
special output is printed on STREAM-SYMBOL and the BODY is skipped along
with the printing of the prefix and suffix. (If the BODY is
not responsible for printing a list, then the first two tests above can
be turned off by supplying NIL for the LIST argument.)
!
CONDITIONAL-NEWLINE KIND &OPTIONAL (STREAM *STANDARD-OUTPUT*) [Function]
CONDITIONAL-NEWLINE is the functional equivalent of ~_. STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions (i.e., NIL stands for
*STANDARD-OUTPUT* and T stands for *TERMINAL-IO*). The KIND argument
specifies the style of conditional newline. It must be one of :LINEAR,
:FILL, :MISER, or :MANDATORY. If STREAM is a special stream bound by
WITHIN-LOGICAL-BLOCK, a conditional newline is sent to it. Otherwise,
CONDITIONAL-NEWLINE has no effect. The value NIL is always returned.
LOGICAL-BLOCK-INDENT RELATIVE-TO N &OPTIONAL (STREAM *STANDARD-OUTPUT*) [Function]
LOGICAL-BLOCK-INDENT is the functional equivalent of ~I. STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions. N specifies the indentation in
ems. If RELATIVE-TO is :BLOCK, this indentation is relative to the
start of the enclosing block (as for ~I). If RELATIVE-TO is :CURRENT,
the indentation is relative to the current output position (as for ~:I).
It is an error for RELATIVE-TO to take on any other value. If STREAM is
a special stream bound by WITHIN-LOGICAL-BLOCK, LOGICAL-BLOCK-INDENT
sets the indentation in the innermost enclosing logical block.
Otherwise, LOGICAL-BLOCK-INDENT has no effect. The value NIL is always
returned.
LOGICAL-BLOCK-TAB KIND COLNUM COLINC &OPTIONAL (STREAM *STANDARD-OUTPUT*)
LOGICAL-BLOCK-TAB is the functional equivalent of ~T. STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions. The arguments COLNUM and COLINC
correspond to the two numeric parameters to ~T and are in terms of ems.
The KIND argument specifies the style of tabbing. It must be one of
:LINE (tab using ~T), :BLOCK (tab using ~:T), :LINE-RELATIVE (tab using
~@T), or :BLOCK-RELATIVE (tab using ~:@T). If STREAM is a special
stream bound by WITHIN-LOGICAL-BLOCK, tabbing is performed. Otherwise,
LOGICAL-BLOCK-TAB has no effect. The value NIL is always returned.
LOGICAL-BLOCK-POP ARGS &OPTIONAL (STREAM *STANDARD-OUTPUT*) [Macro]
LOGICAL-BLOCK-COUNT &OPTIONAL (STREAM *STANDARD-OUTPUT*) [Macro]
LOGICAL-BLOCK-POP is identical to POP except that it supports
*PRINT-LENGTH* and *PRINT-CIRCLE*. It is an error to use
LOGICAL-BLOCK-POP anywhere other than syntactically nested within a
call on WITHIN-LOGICAL-BLOCK.
ARGS must be a symbol or expression acceptable to POP. STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions. If STREAM is a special stream
bound by WITHIN-LOGICAL-BLOCK, then LOGICAL-BLOCK-POP performs the
special operations described below. Otherwise, LOGICAL-BLOCK-POP is
identical to POP.
!
Each time LOGICAL-BLOCK-POP is called, it performs three tests. if
ARGS is not a cons, ". " is printed followed by ARGS. If
*PRINT-LENGTH* is NIL and LOGICAL-BLOCK-POP has already been called
*PRINT-LENGTH* times within the immediately containing logical block,
"..." is printed. If *PRINT-CIRCLE* is not NIL, and ARGS is a circular
reference, then ". " is printed followed by an appropriate #n# marker.
If either of the three conditions above occurs, the special output is
printed on :STREAM and the execution of the immediately containing
WITHIN-LOGICAL-BLOCK is terminated except for the printing of the
suffix. Otherwise, LOGICAL-BLOCK-POP pops the top value off of ARGS
and returns this value.
LOGICAL-BLOCK-COUNT is identical to LOGICAL-BLOCK-POP except that it
does not take an ARGS argument, always returns NIL, and only performs
the second test discussed above. It is useful when the components of a
non-list are being printed.
Using the functions above, TABULAR-STYLE could be defined as follows.
(defun tabular-style (s list &optional (colon? T) atsign? (tabsize nil))
(declare (ignore atsign?))
(if (null tabsize) (setq tabsize 16))
(within-logical-block (s list :prefix (if colon? "(" "")
:suffix (if colon? ")" ""))
(when list
(loop (write (logical-block-pop list s) :stream s)
(if (null list) (return nil))
(write-char #\space s)
(logical-block-tab :block-relative 0 tabsize s)
(conditional-newline :fill s)))))
The function below prints a vector using #(...) notation.
(defun print-vector (v *standard-output*)
(within-logical-block (nil nil :prefix "#(" :suffix ")")
(let ((end (length v)) (i 0))
(when (plusp end)
(loop (logical-block-count)
(write (aref v i))
(if (= (incf i) end) (return nil))
(write-char #\space)
(conditional-newline :fill))))))
FILL-STYLE STREAM LIST &OPTIONAL (COLON? T) ATSIGN?
LINEAR-STYLE STREAM LIST &OPTIONAL (COLON? T) ATSIGN?
TABULAR-STYLE STREAM LIST &OPTIONAL (COLON? T) ATSIGN? (TABSIZE 16)
The directives ~/fill-style/, ~/linear-style/, and ~/tabular-style/ are
supported by the three functions above. These functions can also be
called directly by the user. Each function prints parentheses around
the output if an only if COLON? (default T) is not NIL. Each function
ignores its ATSIGN? argument and returns NIL. (These arguments are
optional to facilitate the direct use of the three functions.) Each
function handles abbreviation and circularity detection correctly, and
uses WRITE to print LIST when given a non-list argument.
The function LINEAR-STYLE prints a list either all on one line, or with
each element on a separate line. The function FILL-STYLE prints a list
with as many elements as possible on each line. The function
TABULAR-STYLE is the same as FILL-STYLE except that it prints the
elements so that they line up in columns. This function takes an
additional argument TABSIZE (default 16) that specifies the column
spacing in ems.
!
Print Dispatch Tables
Pretty printing is directed by print dispatch tables.
COPY-PRINT-DISPATCH &optional (table *PRINT-DISPATCH*) [function]
A copy is made of table, which defaults to the current print dispatch
table. If table is NIL, a copy is made of the initial print dispatch
table.
DEFINE-PRINT-DISPATCH type-specifier options &body function [macro]
This puts an entry into a print dispatch table. The type-specifier
(which is implicitly quoted) is the key of the entry. The function
specifies how to pretty print the indicated type of object. When
appropriate, the function is called with two arguments: an output
stream and the object to print. Any values returned by the function are
ignored. The options are a list of pairs containing a keyword and a
value. Three different keywords are supported:
(:TABLE table)
Specifies the table (default *PRINT-DISPATCH*) to put the dispatch entry
into.
(:PRIORITY number)
Specifies a priority (default 0) used to resolve conflicts when an object
matches more than one entry.
(:NAME name)
Specifies a name to be given to function. This makes it possible to
reuse the function---e.g., in another call on DEFINE-PRINT-DISPATCH.
Before doing anything else, DEFINE-PRINT-DISPATCH removes any existing
entry with a type specifier EQUAL to the given type specifier. A new
entry containing the given priority and function is then created.
The function in a DEFINE-PRINT-DISPATCH call can be specified in five
different ways. First, the function can be NIL. In this case, no new
entry is made after the old entry (if any) is removed. Second, the
function can be omitted altogether. In this case, the standard pretty
printing function (if any) corresponding to the type specifier is entered
into the table. Third, the function can be an argument list followed by a
body consisting of one or more statements. (The use of &REST X in the
argument list below makes it possible to use ~/RATIO-PRINT/ in a FORMAT
string.)
(define-print-dispatch ratio ((:name ratio-print))
(s obj &rest x)
(declare (ignore x))
(format s #"#.(/ ~W ~W)" (numerator obj) (denominator obj)))
(pprint '(2/3 -4/5)) prints: (#.(/ 2 3) #.(/ -4 5))
!
Fourth, the function can be an instance of #"...".
(define-print-dispatch (and ratio (satisfies plusp))
((:priority 1))
#"(+ ~/ratio-print/)")
(pprint '(2/3 -4/5)) prints: ((+ #.(/ 2 3)) #.(/ -4 5))
Fifth, the function can be a sharp-quoted function name. The definition
below shows the default method used for printing lists that represent data,
rather than programs. (As shown in the definition of LINEAR-STYLE above,
LINEAR-STYLE, FILL-STYLE, and TABULAR-STYLE are all defined with their
COLON? and ATSIGN? arguments optional so that they can be used as
DEFINE-PRINT-DISPATCH functions.)
(define-print-dispatch cons ((:priority -10)) #'fill-style)
The entry to use for printing an object is selected by looking at the
entries in *PRINT-DISPATCH* in the order of their priorities. The first
entry whose type specifier matches the object is chosen. If an object
matches two entries with the same priority, an arbitrary choice is made.
If no entry matches the object, the object is printed as if *PRINT-PRETTY*
were NIL.
(CONS car-type cdr-type) [type specifier]
When used simply as the symbol CONS, this type specifier matches any
cons cell. When used in the form above, it matches a cons cell only if the
car of the cell matches the type specifier car-type and the cdr of
the cell matches the type specifier cdr-type. The cdr-type can
be omitted in which case it defaults to T.
The examples below show three of the predefined pretty printing functions
for Lisp code. By default, function calls are printed in the standard
way---i.e, either all on one line or with the arguments one to a line
indented after the function name.
(define-print-dispatch (cons (and symbol (satisfies fboundp)))
((:priority -5))
#"~:<~W~↑ ~:I~@_~@{~W~↑ ~_~}~:>")
Lists beginning with COND are printed the same way as function calls,
except that the clauses are always printed in linear style, rather than in
the format suggested by their cars.
(define-print-dispatch (cons (member cond)) ()
#"~:<~W~↑ ~:I~@_~@{~:/linear-style/~↑ ~_~}~:>")
Lists beginning with QUOTE are printed using the standard "'" syntax. Note
the care taken to ensure that data lists that happen to begin with QUOTE
will be printed legibly.
(define-print-dispatch (cons (member quote)) () (s list)
(if (and (consp (cdr list)) (null (cddr list)))
(format s #"'~W" (cadr list))
(fill-style s list)))
!
In addition to the last four entries shown above, the initial print
dispatch table contains approximately fifty additional entries with type
specifiers of the form (CONS (MEMBER symbol)) and priority zero for various
Lisp special forms and macros. There are no other predefined pretty
printing functions for data structures other than lists. However, as shown
below, such entries can easily be defined.
(defstruct family mom kids)
(define-print-dispatch family () (s f)
(format s #"~@<#<~;~W and ~2I~_~/fill-style/~;>~:>"
(family-mom f) (family-kids f)))
The pretty printing function for the structure FAMILY specifies how to
adjust the layout of the output so that it can fit aesthetically into a
variety of line widths. In addition, it obeys the printer control
variables *PRINT-LEVEL*, *PRINT-LENGTH*, *PRINT-LINES*, *PRINT-CIRCLE*, and
*PRINT-ESCAPE*, and can tolerate several different kinds of malformity in
the data structure. The output below shows what happens with line width
25, *PRINT-PRETTY T, *PRINT-ESCAPE* NIL, and a malformed KIDS list.
(write (list 'principle-family
(make-family :mom "Lucy"
:kids '("Mark" "Bob" . "Dan"))))
(PRINCIPLE-FAMILY
#<Lucy and
Mark Bob . Dan>)
Note that a pretty printing function for a structure is different from the
structure's print function. While print functions are permanently
associated with a structure, pretty printing functions are stored in print
dispatch tables and can be rapidly changed to reflect different printing
needs. If there is no pretty printing function for a structure in the
current print dispatch table, the print function (if any) is used instead.
[End of attached document]
∂22-Mar-89 1104 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 22 Mar 89 11:01:59 PST
Received: from fafnir.think.com by Think.COM; Wed, 22 Mar 89 13:05:17 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 22 Mar 89 12:56:48 EST
Received: by verdi.think.com; Wed, 22 Mar 89 12:53:33 EST
Date: Wed, 22 Mar 89 12:53:33 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903221753.AA26200@verdi.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 21 Mar 89 19:28 EST <19890322002858.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
After yet more careful study I conclude that the version 9 proposal
is not a clarification but a change. Here is the reasoning.
There is only one way in Common Lisp to adjust an array, and that is by
calling ADJUST-ARRAY. (The definition of VECTOR-PUSH-EXTEND, p. 296,
specifically says that it uses ADJUST-ARRAY, and other places in the
language, such as FORMAT with a string as first argument, refer to
VECTOR-PUSH-EXTEND.)
Hence it is senseless to speak of an array that is "adjustable" but cannot
under any circumstances legitimately be given to ADJUST-ARRAY.
Now look at the definition of ADJUST-ARRAY, pp. 297-98.
It is not permitted to call ADJUST-ARRAY on an array that was not
created with the :ADJUSTABLE option. The predicate ADJUSTABLE-ARRAY-P
may be used to determine whether or not an array is adjustable.
I reason that the first sentence prohibits any array not created with
the :ADJUSTABLE option from being given to ADJUST-ARRAY under any
circumstances. This includes having been tested with ADJUSTABLE-ARRAY-P.
Therefore any array not created with the :ADJUSTABLE option must be
not adjustable. Therefore ADJUSTABLE-ARRAY-P must return NIL when
given such an array. Therefore the following items of the proposal
cannot be true of the current (CLtL) specification:
1. ... Whether ADJUSTABLE-ARRAY-P is
true of some other arrays is unspecified.
b. There is no specified way to create an array for which ADJUSTABLE-ARRAY-P
definitely returns NIL.
Therefore the proposal is a change and not a clarification, and
should be labeled as such.
----------------------------------------------------------------
I think that the following points also require clarification or comment:
(1) What is a compiler permitted to conclude from the declarations
(DECLARE (SIMPLE-ARRAY FOO)
(TYPE (AND ARRAY (NOT SIMPLE-ARRAY)) BAR))
?
(2) What is a program permitted to conclude from the test
(TYPEP X 'SIMPLE-ARRAY)
both when it returns true and when it returns false?
(3) I believe that much of the controversy stems from disagreement over
whether the definition on page 28 is considered to be an implication
or an equivalence. That is, I think everyone agrees that the
sentence could be rephrased as:
An array is simple __________ it is is not displaced to another
array, has no fill pointer, and is not adjustable.
but they disagree on whether the blank should read "if" or "iff".
The proposal should state explicitly which of these two interpretations
(or what third interpretation) is assumed.
--Guy
∂22-Mar-89 1612 CL-Cleanup-mailer Issue: PRETTY-PRINT-INTERFACE, version 4
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Mar 89 16:11:53 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 563289; Wed 22-Mar-89 19:11:28 EST
Date: Wed, 22 Mar 89 19:11 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PRETTY-PRINT-INTERFACE, version 4
To: dick@wheaties.ai.mit.edu
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8903221854.AA10669@wheat-chex.ai.mit.edu>
Message-ID: <19890323001116.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Version 4 of the proposal looks good to me. I noticed one typo,
in the arguments of WITHIN-LOGICAL-BLOCK the word &KEY is missing.
I still think that the FORMAT-based interface and the functional
interface should be separated for voting purposes.
∂22-Mar-89 2239 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 22 Mar 89 22:39:31 PST
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88);
Thu, 23 Mar 89 00:40:28 CST id AA25401 for cl-cleanup@SAIL.STANFORD.EDU
Posted-Date: Thu, 23 Mar 89 00:38:34 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
id AA25833; Thu, 23 Mar 89 00:38:34 CST
Date: Thu, 23 Mar 89 00:38:34 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8903230638.AA25833@pavo.src.honeywell.com>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon's message of Wed, 22 Mar 89 21:59 EST <19890323025928.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
Allow the value of a pathname's directory component to be a list. The
car of the list may be either of the symbols :ABSOLUTE or :RELATIVE.
Each remaining element of the list is a string or one of the keyword
symbols listed below...
I picked on Kent for not specifying that the elements of the list should be
either strings or keywords, then after reading PATHNAME-WILD, I think that
we should not preclude implmentations from defining "regular expression",
or "user home directory"components. E.g.
(pathname-directory x) => (:absolute "foo" #<regexp "Fo" :wild "bar">)
(pathname-directory x) => (#<user-homedir "alarson"> "bar" "baz")
I'm not advocating adding such a feature, just not precluding us from
defining one in the future. Perhaps we should add a line something like:
"Implementations may permit objects of types other than keywords and
strings as elements of the pathname-directory list."
Even without a statement of this kind, I support the proposal.
∂23-Mar-89 0645 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Mar 89 06:45:08 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA00648; Thu, 23 Mar 89 07:45:05 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA12384; Thu, 23 Mar 89 07:44:50 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903231444.AA12384@defun.utah.edu>
Date: Thu, 23 Mar 89 07:44:49 MST
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Wed, 22 Mar 89 23:30 EST
[removed x3j13; added cl-cleanup]
I don't really like any of these proposals.
Proposal CANONICALIZE is broken because it doesn't provide any way to
specify that a pathname component should be in *exactly* the case you
provide (including all upper or all lower) on file systems that
support mixed case.
Proposals NEW-COMMON-ACCESSORS and NEW-LOCAL-ACCESSORS add too many
functions to the language.
Proposal KEYWORD-ARGUMENT is the least objectionable of the bunch, but
I still don't like it. I still claim that there is no portable way to
use MAKE-PATHNAME (even if the problems with case are involved),
because there are other problems with things like the lengths of
strings and what characters are valid in the various pathname fields
on different file systems.
-Sandra
-------
∂23-Mar-89 0804 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 23 Mar 89 08:03:56 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA10286; Thu, 23 Mar 89 11:03:37 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA04203; Thu, 23 Mar 89 11:05:32 EST
Message-Id: <8903231605.AA04203@mist.>
To: "sandra%defun@cs.utah.edu"@Multimax.encore.com (Sandra J Loosemore)
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)
In-Reply-To: Your message of Thu, 23 Mar 89 07:44:49 -0700.
<8903231444.AA12384@defun.utah.edu>
Date: Thu, 23 Mar 89 11:05:29 EST
From: Dan L. Pierson <pierson@mist.encore.com>
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Date: Thu, 23 Mar 89 07:44:49 MST
Proposal KEYWORD-ARGUMENT is the least objectionable of the bunch, but
I still don't like it. I still claim that there is no portable way to
use MAKE-PATHNAME (even if the problems with case are involved),
because there are other problems with things like the lengths of
strings and what characters are valid in the various pathname fields
on different file systems.
Are you saying that there is no portable way to make any desired
pathname or that even if you limit your program to a "portable" subset
of file names that there is no portable way to manipulate them.
Such a portable subset might be a single alphabetic case, digits, 0 or
1 period, and no more than 14 characters total. You might be able to
add underscore are well.
∂23-Mar-89 0805 CL-Cleanup-mailer Re: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 23 Mar 89 08:05:17 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA10302; Thu, 23 Mar 89 11:05:08 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA04217; Thu, 23 Mar 89 11:07:03 EST
Message-Id: <8903231607.AA04217@mist.>
To: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
Date: Thu, 23 Mar 89 11:07:02 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Date: Thu, 23 Mar 89 10:53:28 EST
From: Dan L. Pierson <pierson>
I'm not advocating adding such a feature, just not precluding us from
defining one in the future. Perhaps we should add a line something like:
"Implementations may permit objects of types other than keywords and
strings as elements of the pathname-directory list."
Even without a statement of this kind, I support the proposal.
Since we seem to be adopting an overall conformance extensions
position of "everything not explicity permitted is forbidden", I
strongly support this change. While I will probably vote for the
proposal without the change, note that raising this issue then
rejecting the change amounts to an explicit statement by X3J13 that
such extensions are prohibited. I think this would be very
unfortunate.
∂23-Mar-89 0820 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Mar 89 08:20:42 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA03358; Thu, 23 Mar 89 09:20:38 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA12460; Thu, 23 Mar 89 09:20:35 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903231620.AA12460@defun.utah.edu>
Date: Thu, 23 Mar 89 09:20:34 MST
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)
To: Dan L. Pierson <pierson@mist.encore.com>
Cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: Dan L. Pierson <pierson@mist.encore.com>, Thu, 23 Mar 89 11:05:29 EST
> Date: Thu, 23 Mar 89 11:05:29 EST
> From: Dan L. Pierson <pierson@mist.encore.com>
>
> Are you saying that there is no portable way to make any desired
> pathname or that even if you limit your program to a "portable" subset
> of file names that there is no portable way to manipulate them.
>
> Such a portable subset might be a single alphabetic case, digits, 0 or
> 1 period, and no more than 14 characters total. You might be able to
> add underscore are well.
Yup, that's what I'm saying. We ran into this problem while trying to
port PCLS to the Cray running CTSS a few years ago. The file system
had no concept of directories or file types, and file names were
restricted to 6 characters.
Also, the Atari ST's file system (and MS-DOS also?) supports only
1-character device names, 8-character file names and 3-character file
types. As I recall, IBM's VM/CMS (and I think MVS/TSO too) delimits
the file name and file type with a space instead of a period.
-Sandra
-------
∂23-Mar-89 0919 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 89 09:18:57 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 563625; Thu 23-Mar-89 12:18:26 EST
Date: Thu, 23 Mar 89 12:18 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)
To: Sandra J Loosemore <sandra%defun@CS.UTAH.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8903231444.AA12384@defun.utah.edu>
Message-ID: <19890323171821.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 23 Mar 89 07:44:49 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
I still claim that there is no portable way to
use MAKE-PATHNAME (even if the problems with case are involved),
because there are other problems with things like the lengths of
strings and what characters are valid in the various pathname fields
on different file systems.
I think there is a big difference between "it is possible to write
non-portable programs using MAKE-PATHNAME" and "it is impossible
to write any useful portable programs using MAKE-PATHNAME."
∂23-Mar-89 1112 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 23 Mar 89 11:12:20 PST
Received: from pitney-bowes ([192.9.200.50]) by heavens-gate.lucid.com id AA03428g; Thu, 23 Mar 89 11:06:43 PST
Received: by pitney-bowes id AA26285g; Thu, 23 Mar 89 11:04:50 PST
Date: Thu, 23 Mar 89 11:04:50 PST
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8903231904.AA26285@pitney-bowes>
To: pierson@mist.encore.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Dan L. Pierson's message of Thu, 23 Mar 89 11:07:02 EST <8903231607.AA04217@mist.>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
I'm also disturbed by the proposed restrictions on the elements of a
pathname-directory list. Why, for example, is it necessary to
preclude a feature that allows variables to appear? E.g., the
following seems like a plausibly useful pair of pathnames:
(:ABSOLUTE *top-of-source-tree* "a" "b" "c")
(:ABSOLUTE *top-of-destination-tree* "a" "b" "c")
or even:
(:ABSOLUTE *top-of-source-tree* . *relative-dir-path*)
(:ABSOLUTE *top-of-destination-tree* . *relative-dir-path*)
[There's probably better syntax than a dotted pair, but you know what
I mean.]
I'm not saying I need or even want this particular feature, but I'm
pretty sure I don't want to have it prohibited just because it hadn't
occurred to anyone yet.
[Btw, I think Alarson's example for home dir could be accomomdated as
(... :HOME "alarson" ...) in the spirit of the proposal. Most
plausible structures could probably be handled similarly, but perhaps
clumsily.]
jlm
∂23-Mar-89 1132 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 89 11:32:32 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 563772; Thu 23-Mar-89 14:31:25 EST
Date: Thu, 23 Mar 89 14:31 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
To: jlm@Lucid.COM
cc: pierson@Mist.Encore.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8903231904.AA26285@pitney-bowes>
Message-ID: <890323143103.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
Please see the issue writeup for PATHNAME-EXTENSIONS which I'm mailing out to
X3J13 in a little while. I think it is the correct way to deal with
`[not] precluding extensions.' It basically allows us to establish a model
for how CL pathnames work, and then to selectively violate that model in a
way that is detectable by portable programs. My hope is that it will allow
you to vote in favor of the PATHNAME-SUBDIRECTORY-LIST proposal in some form
(and perhaps other pathname proposals as well) without worrying that it's going
overly constrain you for some idiosyncratic feature that you wanted but couldn't
get group approval for.
∂23-Mar-89 1205 CL-Cleanup-mailer string OK for :CONC-NAME in DEFSTRUCT?
Received: from arisia (arisia.Xerox.COM) by SAIL.Stanford.EDU with TCP; 23 Mar 89 12:04:54 PST
Received: from bopp.parc.Xerox.COM by arisia with SMTP
(5.59++/IDA-1.2.6) id AA27611; Thu, 23 Mar 89 12:03:36 PST
Received: by bopp.parc.xerox.com
(5.61+/IDA-1.2.8/gandalf) id AA00266; Thu, 23 Mar 89 12:04:10 PST
Message-Id: <8903232004.AA00266@bopp.parc.xerox.com>
Reply-To: cutting.pa@bopp.parc.xerox.com
Errors-To: <postmaster@bopp.parc.xerox.com>
Date: Thu, 23 Mar 89 12:04:10 PST
From: cutting.pa@bopp.parc.xerox.com
To: cl-cleanup@SAIL.STANFORD.EDU
Cc: cutting.pa@bopp.parc.xerox.com
Subject: string OK for :CONC-NAME in DEFSTRUCT?
CLtL does not specify whether the :CONC-NAME option to DEFSTRUCT must
be a symbol, or whether strings are allowed. Its example uses a
symbol, but the default name construction for :COPIER and :PREDICATE
are described in terms of strings, providing some precedence for strings.
Xerox & Lucid allow strings, while Franz does not. Allowing strings
seems reasonable to me, as no aspect of the symbol is used except for
its name.
Has this question been addressed previously by the cleanup committee?
If not I will gladly writeup a proposal.
Doug
∂23-Mar-89 1225 CL-Cleanup-mailer Meeting 1 hour before plenary session?
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Mar 89 12:25:40 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 23 MAR 89 12:21:34 PST
Date: 23 Mar 89 12:19 PST
From: masinter.pa@Xerox.COM
Subject: Meeting 1 hour before plenary session?
To: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <890323-122134-5313@Xerox>
I'm back near a mailbox. Can we get together an hour before the main
session to go over the cleanup report agenda? I want to order the cleanup
issues so that we handle the "important" ones first. I roughly think that
means:
a) fix the cleanups that were previously broken
b) clarifications
c) changes
c) additions
within each category, order mainly by age: handle oldest issues first. But
then, there are some of these that are more 'important' that we'll want to
mess up the order.
I plan to put together a proposal for dealing with these over the next few
days and will mail it out, but you might want to come prepared with your
own list of "things that are critically important to get voted on this
meeting".
∂23-Mar-89 1504 CL-Cleanup-mailer Meeting 1 hour before plenary session?
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Mar 89 12:25:40 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 23 MAR 89 12:21:34 PST
Date: 23 Mar 89 12:19 PST
From: masinter.pa@Xerox.COM
Subject: Meeting 1 hour before plenary session?
To: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <890323-122134-5313@Xerox>
I'm back near a mailbox. Can we get together an hour before the main
session to go over the cleanup report agenda? I want to order the cleanup
issues so that we handle the "important" ones first. I roughly think that
means:
a) fix the cleanups that were previously broken
b) clarifications
c) changes
c) additions
within each category, order mainly by age: handle oldest issues first. But
then, there are some of these that are more 'important' that we'll want to
mess up the order.
I plan to put together a proposal for dealing with these over the next few
days and will mail it out, but you might want to come prepared with your
own list of "things that are critically important to get voted on this
meeting".
∂23-Mar-89 1518 CL-Cleanup-mailer Issue: READ-CASE-SENSITIVITY (Version 2)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 23 Mar 89 15:17:15 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa11717; 23 Mar 89 23:10 GMT
Date: Thu, 23 Mar 89 23:11:13 GMT
Message-Id: <2240.8903232311@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Issue: READ-CASE-SENSITIVITY (Version 2)
To: CL-Cleanup@sail.stanford.edu
Cc: Kent M Pitman <KMP@scrc-stony-brook.arpa>, Masinter.PA@xerox.com,
richard%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
It's very late, but here it is.
Issue: READ-CASE-SENSITIVITY
Forum: Cleanup
References: CLtL p 334 ff: What the Read Function Accepts,
especially p 337, step 8, point 1.
CLtL p 360 ff: The Readtable
COPY-READTABLE (CLtL, p 361)
*PRINT-CASE* (CLtL, p 372)
Category: ADDITION/CHANGE
Edit history: Version 1, 15-Feb-89, by Dalton
Version 2, 23-Mar-89, by Dalton,
(completely new proposal after comments from
Pitman, Gray, Masinter, and R.Tobin@uk.ac.ed)
Problem Description:
The Common Lisp reader always converts unescaped constituent
characters to upper case. (See CLtL, p 337, step 8, point 1.)
This behavior is not always desirable.
1. Lisp applications often use the Lisp reader to read their data.
This is often significantly easier than writing input routines
from scratch, especially if the input can be structured as lists.
However, certain applications want to make use of case distinctions,
and Common Lisp makes this unreasonably difficult. (You must define
every letter as a read macro and have the macro function read the
rest of the symbol, or else you must write a reader from scratch.)
2. Some programming languages distinguish between upper and lower
case in identifiers, and useful conventions are often built around
such distinctions. For example, in C, constants are often written
in upper case and variables in lower. In Mesa(?) and Smalltalk(?),
a capital letter is used to indicate the beginning of a new word
in identifiers made up of several words. In Edinburgh Prolog,
variables begin with upper-case letters and constant symbols do
not. The case-insensitivity of the Common Lisp reader makes
it difficult to use conventions of this sort.
Proposal (READ-CASE-SENSITIVITY:READTABLE-KEYWORDS)
Define a new settable function, (READTABLE-CASE <readtable>) to
control the reader's interpretation of case. The following values
may be given:
:UPCASE -- convert unescaped characters to upper-case, as now.
:DOWNCASE -- convert unescaped characters to lower-case.
:PRESERVE -- don't convert, leaving lower-case letters in lower
case and upper-case characters in upper case.
:INVERT -- convert lower-case to upper and upper-case to lower.
COPY-READTABLE copies the setting of READTABLE-CASE. The value of
READTABLE-CASE for the standard readtable is :UPCASE.
The READTABLE-CASE of a readtable also has significance when
printing. The case in which letters are printed is determined as
follows:
When READ-CASE is :UPCASE, upper-case letters are printed in the
case specified by *PRINT-CASE*.
When READ-CASE is :DOWNCASE, lower-case letters are printed in
the case specified by *PRINT-CASE*.
When READ-CASE is :PRESERVE, letters are printed in their own
case.
When READ-CASE is :INVERT, the case of all letters is inverted.
(The behavior when *PRINT-CASE* is :CAPITALIZE is like :UPCASE for
the first character and :DOWNCASE for the rest.)
The rules for escaping letters are also affected by the READTABLE-CASE.
If *PRINT-ESCAPE* is true, letters are escaped as follows:
When READ-CASE is :UPCASE, all lower-case letters must be escaped.
When READ-CASE is :DOWNCASE, all upper-case letters must be escaped.
Otherwise, no letters need be escaped.
Proposal (READ-CASE-SENSITIVITY:READTABLE-FUNCTION)
Define a new settable function (READTABLE-CHARACTER-TRANSLATION
<readtable>) to control the reader's interpretation of unescaped
constituent characters. The value may be any function of type
(FUNCTION (CHARACTER) CHARACTER). Where the reader now converts
such characters to upper case it should instead call the function
that is the value of READTABLE-CHARACTER-TRANSLATION for the current
readtable. (See CLtL, page 337, step 8, point 1.)
COPY-READTABLE copies the setting of READTABLE-CHARACTER-TRANSLATION.
The value for the standard readtable is CHAR-UPCASE.
The READTABLE-CHARACTER-TRANSLATION of a readtable also has
significance when printing. The reader recognizes certain functions
which control the reader's interpretation of case and alters its
behavior accordingly. This behavior is given by the following
correspondence between functions and the keywords described above.
[This is just to avoid repeating a lot of text.]
function keyword
CHAR-UPCASE :UPCASE
CHAR-DOWNCASE :DOWNCASE
IDENTITY :PRESERVE
CHAR-INVERT-CASE :INVERT
The function can be given either as a symbol or as one of the values
#'CHAR-UPCASE, #'CHAR-DOWNCASE, #'IDENTITY, #'CHAR-INVERT-CASE.
If the READTABLE-CHARACTER-TRANSLATION is not one of the functions
listed above, letters are always printed in their own case (in
particular, *PRINT-CASE* has no effect), and all characters in
symbol names are escaped if *PRINT-ESCAPE* is true.
Define a new function CHAR-INVERT-CASE of type (FUNCTION (CHARACTER)
CHARACTER) analogous to CHAR-UPCASE and CHAR-DOWNCASE. It attempts
to convert its argument to upper-case if the argument is lower-case
and to lower-case if the argument is upper-case.
Rationale:
There are a number of different ways to achieve case-sensitivity.
These proposals are fairly simple but provide all of the
functionality that one could reasonably expect.
By using a property of the readtable, we avoid introducing a new
special variable. Any code that wishes to control all of the
reader's parameters already takes *READTABLE* into account. A new
special variable would require such code to change.
:DOWNCASE is included for symmetry with :UPCASE. :INVERT is
included so that case conventions could be used in Common Lisp code
without requiring that the names symbols in the "LISP" package be
written in upper case. (Opinions vary as to whether is is advisable
to use such conventions, but this proposal leaves that choice to the
user.)
In order to avoid complex interactions between the case setting of
the readtable and *PRINT-CASE*, this proposal specifies a
significance for *PRINT-CASE* only when the case setting is :UPCASE
or :DOWNCASE. The meaning of *PRINT-CASE* when the readtable
setting is :DOWNCASE was chosen for its simplicity and for symmetry
with :UPCASE while still being useful.
Test Case:
;; keyword version
(let ((rt (copy-readtable nil)))
(mapcar
#'(lambda (case)
(setf (readtable-case rt) case)
(read-from-string "Zebra"))
'(:upcase :downcase :preserve :invert)))
=> (ZEBRA |zebra| |Zebra| |zEBRA|) ;as printed with the standard
;readtable and *print-case* :upcase
Current Practice:
While there may not be any current implementation that supports
exactly this proposal, several implementations provide some means
for changing case sensitivity.
Franz Inc's ExCL has a function, EXCL:SET-CASE-MODE, that sets both
the "preferred case" (the case of character in the print names of
standard symbols such as CAR) and whether or not the reader is case-
sensitive.
In Symbolics Common Lisp, the function SET-CHARACTER-TRANSLATION
can be used to make the translation of a letter be that same letter,
thus achieving case-sensitivity.
Xerox Medley has a function for setting a readtable flag that
determines case sensitivity.
Cost to Implementors:
Fairly small. The reader will be slightly slower and readtables
will be slightly more complex.
Cost to Users:
Slight. Programmers must already take into account the possibility
that *READTABLE* will be a non-standard readtable. Case-sensitivity
is no worse than character macros in this respect.
Cost of Non-Adoption:
Applications that want to read mixed-case expressions will not
be able to use the Common Lisp reader to do so (except, perhaps,
by tortuous use of read macros).
Programming styles that rely on case distinctions (without escape
characters) will be effectively impossible in Common Lisp.
Benefits:
Applications will be able to read mixed-case expressions.
Programmers will be able to make use of case distinctions.
Aesthetics:
For the proposals:
The language will have greater symmetry, because it will be
possible to control the treatment of case on both input and output
instead of only on output (as is now the case).
The language will look less old-fashioned.
Against the proposals:
It is, perhaps, inconsistent to control case-sensitivity by a
readtable operation when other aspects of the reader, such as the
input base and the default float format (not to mention the
package), are controlled by special variables. However, it can be
argued that character-level syntax is determined chiefly by the
readtable. Case-sensitivity can be seen as analogous to character
macros in this respect.
Keywords vs function
The keyword proposal is somewhat simpler and avoids raising the
possibility of character translation that applies in general and
not just for unescaped constituents.
The function proposal is perhaps more elegant.
Discussion:
Dalton supports both proposals but slightly prefers READTABLE-CASE.
Version 1 of the proposal suggested a new global variable rather
than a property of the readtable. Pitman was strongly opposed to
that proposal and gave convincing arguments that it should be
dropped. Gray suggested that the readtable property should be a
function.
∂23-Mar-89 1534 CL-Cleanup-mailer Re: New cleanup issues
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Mar 89 15:32:34 PST
Received: from Semillon.ms by ArpaGateway.ms ; 23 MAR 89 13:01:56 PST
Date: 23 Mar 89 13:01 PST
From: masinter.pa@Xerox.COM
Subject: Re: New cleanup issues
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Tue, 21 Mar 89 18:01 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: Masinter.pa@Xerox.COM, CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <890323-130156-5430@Xerox>
Thanks. I'm merging them into the master list, and hope to get a master
hardcopy off to Mathis sometime today...
∂23-Mar-89 1538 CL-Cleanup-mailer Re: Issue: FIXNUM-NON-PORTABLE, v.5
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Mar 89 15:32:54 PST
Received: from Semillon.ms by ArpaGateway.ms ; 23 MAR 89 13:14:25 PST
Date: 23 Mar 89 13:13 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: FIXNUM-NON-PORTABLE, v.5
In-reply-to: Guy Steele <gls@Think.COM>'s message of Mon, 20 Mar 89
11:45:31 EST
To: Guy Steele <gls@Think.COM>
cc: Moon@stony-brook.scrc.symbolics.com, masinter.pa@Xerox.COM,
cl-cleanup@sail.stanford.edu
Message-ID: <890323-131425-5460@Xerox>
Sorry, yes, I blew it. This is what I've saved as "passed":
Status: Passed Jan 89 X3J13, as amended
Issue: FIXNUM-NON-PORTABLE
References: CLtL p. 14, 34, 43, 231
Category: CHANGE, CLARIFICATION
Edit History: Version 1, 11-Jul-88, Sandra Loosemore
Version 2, 15-Sep-88, Masinter
Version 3, 23-Sep-88, Masinter
Version 4, 7-Dec-88, Masinter (two proposals)
Version 5, 16-Mar-89, Masinter (incorporate amendments)
Version 6, 17-Mar-89, Masinter (incorporate amendments correctly)
Problem Description:
Implementations of Common Lisp are required to support two disjoint
subsets of integers, fixnums and bignums, with the promise that
fixnums have a more efficient representation. However, nothing is
guaranteed about the range of integers which are fixnums: "Exactly
which integers are fixnums is implementation-dependent; typically they
will be those integers in the range -2**n to 2**n - 1, inclusive, for
some n not less than 15."
There are few uses of the fixnum type that are portable, given the
current definition. In particular, many programmers use FIXNUM type
declarations where they really mean "small integer".
While most Common Lisp implementations have a FIXNUM range
which is a subset of integers represeted and operated on most
efficiently, many also have several other subranges. The
partitioning of INTEGER into BIGNUM and FIXNUM is merely
confusing in these implementations, and not useful.
CLtL p14 and p34 disagree about BIGNUM. One says that
FIXNUM and BIGNUM are an exhaustive partition of the
integer space, the other says they might not be!
Proposal: FIXNUM-NONPORTABLE:TIGHTEN-DEFINITION
(1) Change the description of the type FIXNUM to reflect that it is
required to be a supertype of (SIGNED-BYTE 16).
(2) Define BIGNUM to be exactly (AND INTEGER (NOT FIXNUM))
(3) require that (<= ARRAY-DIMENSION-LIMIT MOST-POSITIVE-FIXNUM)
Example:
Consider an implementation with three numeric representations:
Fast (INTEGER -1024 1023)
Immediate 29 bits
Extended Multi-precision
Such an implementation would have to define
FIXNUM to be (OR Fast Immediate). BIGNUM
would then refer to multi-precision integers.
Rationale:
Many programmers already use FIXNUM to mean "small integer"; this
proposal makes this usage portable.
However, there is little portable use for the type BIGNUM, and it
is inconsistent with many current implementation techniques.
Removing it is an incompatible change for a weak reason.
Current Practice:
Xerox Common Lisp has 17-bit fixnums. Most other Common Lisp
implementations have fixnum ranges of 24 bits or larger. We know
of no implementation that currently violates the proposed minimum
size.
Several existing Common Lisp implementations have more than two
representations for integers, such that the FIXNUM/BIGNUM distinction
is confusing; they define BIGNUM to cover all of the larger number
types.
Cost to implementors:
Slight. All implementations we know of already define FIXNUMs to be at
least 16 bits.
Cost to users:
Slight.
Benefits:
The FIXNUM type specifier would have a portable interpretation.
The language would be less confusing.
Discussion:
There was little consensus on whether to leave BIGNUM in the language.
Earlier discussion of a related proposal contained several other more
controversial components (adding a constant MAX-INTEGER-LENGTH, allowing
MOST-POSITIVE-FIXNUM to be NIL as well as an integer.) This proposal
is an attempt to address the part that cleanup committee seemed to agree
on.
It is possible that an implementation have a single representation for all
integers, and no way to identify any efficient range of integers. Those
implementations might need to set MOST-POSITIVE-FIXNUM
and MOST-NEGATIVE-FIXNUM to arbitrary values, consistent with
the requirement that (SIGNED-BYTE 16) is a subtype of FIXNUM.
Other alternatives considered (and not necessarily mutually exclusive
with this proposal):
remove the FIXNUM type specifier entirely, while leaving a way
to query what is the most efficient range of integers
leave the range of FIXNUMs unconstrained and introduce a
SMALL-INTEGER type with a fixed range (but no promises about
efficiency) .
It might be possible to specify the required performance behavior
of FIXNUMs more concretely, e.g., specify that the basic integer operations
use algorithms that are not proportional to the size of the data; it
should be just about as fast to add numbers in the middle of the fixnum
range as it is to add, say, 10 and 11. This might be a useful way to
describe
the intent of the FIXNUM range, if not its specification.
∂23-Mar-89 1538 CL-Cleanup-mailer The Revised Cleanup Issue Status List
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Mar 89 15:33:50 PST
Received: from Semillon.ms by ArpaGateway.ms ; 23 MAR 89 13:44:52 PST
Date: 23 Mar 89 13:43 PST
From: masinter.pa@Xerox.COM
to: cl-cleanup@sail.stanford.edu
Subject: The Revised Cleanup Issue Status List
to: X3J13@sail.stanford.edu
Message-ID: <890323-134452-5540@Xerox>
This is the revised (as of 23-Mar-89 13:43:08) complete list of
Cleanup issues that are either:
passed: passed at *any* previous meeting, including Jan 89
pending: have been distributed for the March meeting
in progress: might possibly be distributed for the March meeting,
or that I think are worth pursuing.
Of course, some more might come up or be revived.
I think I have updated versions of all pending and passed
issues stored on arisia.xerox.com under the
clcleanup/pending
clcleanup/passed
directories respectively.
Codes:
! released for Jan 89 meeting
+ passed
* need new version
!*: released, but I know we'll need a new version
+*: passed, but need to reconsider
!*: passed, but need a new version to reconsider
!
+ ADJUST-ARRAY-DISPLACEMENT
Version 4, 23-Nov-87
Status: passed, 1988
+ ADJUST-ARRAY-FILL-POINTER
Version 1, 15-MAR-88
Status: passed, 1988
! ADJUST-ARRAY-NOT-ADJUSTABLE
Synopsis: ADJUST-ARRAY on array made with :ADJUSTABLE NIL: "an error"?
Version 4, 11-Jan-89, Released 12-Jan-89
Status: Accepted with amendments Jan 89 X3J13
Comments: amendment had wording problem.
Version 8, 11-Mar-89, Released 15-Mar-89
Version 9, 17-Mar-89, released 21-mar-89
Comments: (whew!)
Status: ready for vote
+ APPLYHOOK-ENVIRONMENT
Synopsis: remove (useless) env argument to applyhook
Version 2, 10-Jan-89, Released 10-Jan-89
Status: Passed Jan-89 X3J13
+ AREF-1D
14-NOV-87, Version 7
Status: Passed, 1988?
+ ARGUMENTS-UNDERSPECIFIED
Synopsis: Clarify various ranges missing from CLtL
Version 4, 21-Sep-88, Released 4 Dec 88
Status: Passed Jan 89 X3J13
+ ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Synopsis: What do array element-type declarations mean?
Version 9, 31-Oct-88, Released 5 Dec 88
Status: Passed Jan 89 X3J13
+ ASSOC-RASSOC-IF-KEY
Version 4, 23-NOV-87
Status: Passed, 1988?
! BREAK-ON-WARNINGS-OBSOLETE
Synopsis: deprecate *BREAK-ON-WARNINGS* because of *BREAK-ON-SIGNALS*
Version 1, 07-Mar-89, Released 15-Mar-89
Comment: leaves out a case
Status: ready for vote
! CLOS-CONDITIONS
Version 4, 10-Mar-89
Comments: define metaclass of conditions?
Status: pending
+ CLOSE-CONSTRUCTED-STREAMS
Synopsis: What does it mean to CLOSE a constructed stream?
Version 2, 12-Jan-89, Released 12-Jan-89
Status: Proposal ARGUMENT-STREAM-ONLY passed Jan 89 X3J13
!+ CLOSED-STREAM-OPERATIONS
Synopsis: What operations are legal on closed streams?
Version 5, 5-Dec-88, released 5-Dec-88
Status: amended at meeting
Version 7, 14-Feb-89
Status: Passed, as amended, Jan 89 X3J13
Comment: amendment bad; reconsider version 5.
say that INPUT-STREAM-P and OUTPUT-STREAM-P
are undefined on closed streams?
! COERCE-INCOMPLETE
Synopsis: Extend COERCE
Version 3, 7-Mar-89, Released 14-Mar-89
Status: ready for voting
+ COLON-NUMBER
Synopsis: :123 is an error
22-OCT-87, Version 1
Status: Passed, 1988?
! COMMON-TYPE
Version 1, 20-Mar-89, released 21-Mar-89
Status: vote
! COMPLEX-RATIONAL-RESULT
Version 1, 20-Mar-89, released 21-Mar-89
Status: vote
+ COMPILER-WARNING-STREAM
Version 6, 5-JUN-87
Status: Passed, 1988?
+ COMPLEX-ATAN-BRANCH-CUT
Synopsis: tweak upper branch cut in ATAN formula
Version 1, 13-Dec-88, Released 10-Jan-89
Status: Passed Jan 89 X3J13
!* CONDITION-RESTARTS
Synopsis: can't know whether restart is associated with signalling
Version 1, 18-Jan-89, released 16-Mar-89
Comment: (proposed amendments)
Status: need new version
+ CONTAGION-ON-NUMERICAL-COMPARISONS
Version 1, 14-Sep-88, Released 6 Oct 88
Status: passed, Jan 89 X3J13
! COPY-SYMBOL-COPY-PLIST
Version 1, 10-Jan-89, released 16-Mar-89
Status: ready for vote
! COPY-SYMBOL-PRINT-NAME
Version 2, 15-Mar-89, released 16-Mar-89
Status: ready for vote
+ DATA-TYPES-HIERARCHY-UNDERSPECIFIED
4-SEP-88 Version 2
Status: Passed, 1988?
+ DECLARATION-SCOPE
Version 4, 15-Nov-88, Released 9-Dec-88
Status: NO-HOISTING passed Jan 89 X3J13
+ DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Version 3, 13-Jan-89
Status: passed, Jan 89 X3J13
+ DECLARE-FUNCTION-AMBIGUITY
Version 4, 5-Dec-88, Released 5-Dec-88
Status: passed, Jan 89 X3J13
+ DECLARE-MACROS
5-FEB-88, Version 3
Status: Passed, 1988?
+ DECLARE-TYPE-FREE
Version 10, 12-Jan-89
Status: proposal LEXICAL passed Jan 89 X3J13
+ DECODE-UNIVERSAL-TIME-DAYLIGHT
Version 2, 30-Sep-88, Released 6 Oct 88
Status: Passed, Jan 89 x3j13
* DEFMACRO-LAMBDA-LIST
Version 2, 17-Mar-89
Status: ** NEED NEW VERSION **
+ DEFPACKAGE
Version 7, 2-Nov-88, Released 5 Dec 88
Comment: clarify "at variance" in editorial work?
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
Version 3, 8-Jan-89, Released 11-Jan-89
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-DEFAULT-VALUE-EVALUATION
Version 1, 5/13/88
Status: Passed, 1988
+ DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
Version 3, 7 Dec 88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-REDEFINITION
Synopsis: what happens if you redefine a DEFSTRUCT?
Version 3, 6-Feb-89
Status: Passed (as amended) Jan 89 X3J13
+ DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
Version 5, 12-Jan-89
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER
Version 1, 5/13/88
Status: Passed, 1988
+ DEFVAR-DOCUMENTATION
23-NOV-87, Version 2
Status: Passed, 1988?
+ DEFVAR-INIT-TIME
29-MAR-87, Version 2
Status: Passed, 1988?
+ DEFVAR-INITIALIZATION
Version 4 5-JUN-87
Status: Passed, 1988?
+ DESCRIBE-INTERACTIVE
Version 4, 15-Nov-88, Released 7-Dec-88
Synopsis: can DESCRIBE ask user a question?
Status: Proposal NO passed Jan 89 X3J13
! DESCRIBE-UNDERSPECIFIED
Version 1, 10-Mar-89, Released 16-Mar-89
Synopsis: making DESCRIBE generic was wrong; fix
Comments: "and calls DESCRIBE recursively argument if there are ... "
status: need to strike "argument"; then vote
!* DESTRUCTURING-BIND
Version 2, 25-Jan-89, Released 16-Mar-89
Synopsis: add DESTRUCTURING-BIND macro
Comments: (at end) + "can't extend by defining harmless...????"
Status: might need new version before vote
+ DISASSEMBLE-SIDE-EFFECT
Version 3 1/21/88
Status: Passed, 1988
+ DO-SYMBOLS-DUPLICATES
Version 3 23-NOV-87
Status: Passed, 1988?
+ DOTTED-MACRO-FORMS
Version 3, 15-Nov-88, Released 7-Dec-88
Status: passed, Jan 89 X3J13
+ DRIBBLE-TECHNIQUE
14-FEB-88, Version 2
Status: Passed, 1988?
! DYNAMIC-EXTENT
Version 3, 11-Jan-89, released 16-Mar-89
Comments: still some holes
Status: ready for vote?
+ EQUAL-STRUCTURE
Version 6, 11-Jan-89, Released 12-Jan-89
Status: Passed with amendments
Version 7, 15-Mar-89
Status: Passed Jan 89 X3J13 as amended.
* EQUALP-GENERIC
Version 1, 28-Feb-89
Synopsis: make EQUALP generic function
Comments: Various problems being worked on
Status: ** NEED NEW VERSION ***
* ERROR-CHECKING-IN-NUMBERS-CHAPTER
Version 1, 6-Mar-89
Synopsis: define 'should signal', 'might signal' for number fns
Status: ** NEED NEW VERSION **
! ERROR-NOT-HANDLED
Version 1, 25-Sep-88, Released 6-Oct-88 and 14-Mar-89
Status: ready for vote
+ EVAL-OTHER
8-JUN-88, Version 2
Status: Passed, 1988?
! EXIT-EXTENT
Version 6, 8-Jan-89, distributed at Jan89 X3J13
Rereleased 16-Mar-89
Status: tabled Jan89; ready for vote
+ EXPT-RATIO
Version 3, 31-Oct-88, Released 7 Dec 88
Status: passed, Jan 89 X3J13
+ FIXNUM-NON-PORTABLE
Version 4, 7-Dec-88, Released 12-Dec-88
Version 6, 17-Mar-89, as amended
Status: Passed, Jan 89 X3J13, as amended
+ FLET-DECLARATIONS
Version 2, 2 FEB 88
Status: Passed, 1988?
+ FLET-IMPLICIT-BLOCK
Version 6 5-JUN-87
Status: Passed, 1988?
+ FORMAT-ATSIGN-COLON
Version 4 5-JUN-87
Status: Passed, 1988?
+ FORMAT-COLON-UPARROW-SCOPE
Version 3, 5 FEB 88
Status: Passed, 1988?
+ FORMAT-COMMA-INTERVAL
Version 2, 15-JUN-87
Status: Passed, 1988?
+ FORMAT-E-EXPONENT-SIGN
Version 2, 2 Oct 88, Released 6 Oct 88
Status: Passed, Jan 89 X3J13
+ FORMAT-OP-C
11-JUN-87, Version 5
Status: Passed, 1988?
* FORMAT-PLURALS
Synopsis: remove ~P, add ~:@[singular~;plural~]
Status: no proposal
+ FORMAT-PRETTY-PRINT
Version 7, 15 Dec 88, Released 7 Dec 88
Comments: passed, Jan 89 X3j13
+ FUNCTION-CALL-EVALUATION-ORDER
Version 1, 22-MAR-88
Status: Passed, 1988
! FUNCTION-COERCE-TIME
Synopsis: When does SYMBOL-FUNCTION happen in MAPCAR?
Version 2, 16-sep-88, Released 8-Oct-88
Re-released: 16-Mar-89
Status: ready for vote?
+ FUNCTION-COMPOSITION
Synopsis: Add new functions
Version 5, 10-Feb-89
Status: Passed (as amended) Jan 89 X3J13
maybe this was passed as amendment to TEST-NOT-IF-NOT instead
+ FUNCTION-DEFINITION
Version 3, 10-Feb-89
Status: Passed (as amended) Jan 89 X3J13
! FUNCTION-NAME
Comment: renaming of SETF-FUNCTION-VS-MACRO, SETF-PLACES
SETF-FUNCTION-VS-MACRO
Version 3, 4-Nov-87, Released Nov 87
SETF-PLACES
Version 1, 11-Nov-88, Released 9-Dec-88
FUNCTION-NAME
Version 1, 27-Jan-89, Released 16-Mar-89
Status: ready for vote
+ FUNCTION-TYPE
Version 12, 4-SEP-88
Status: Passed, June 1988 X3J13, as amended
+ FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
Synopsis: Change semantics of argument types in function declarations
Version 3, 7-Dec-88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13
+ FUNCTION-TYPE-KEY-NAME
Version 3, 13-FEB-88
Status: Passed, 1988
+ FUNCTION-TYPE-REST-LIST-ELEMENT
Version 5, 14-Nov-88, Released 8-Dec-88
Status: Passed, Jan 89 X3J13
! GENSYM-NAME-STICKINESS
Synopsis: no side effects if optional arg supplied
Version 1, 14-Feb-89, Released 14-Mar-89
Status: comments
Version 3, 20-Mar-89
Status: vote?
+ GET-MACRO-CHARACTER-READTABLE
Version 3, 11-Feb-89
Status: Passed (as amended) Jan 89 X3J13
+ GET-SETF-METHOD-ENVIRONMENT
Version 5 13-JUL-87
Status: Passed, 1988?
! HASH-TABLE-ACCESS
Synopsis: Add new accessors for hash-table properties
Version 1, 13-Sep-88 released 8-Oct-88
Version 2, 13 Oct 88, released 16-Mar-89
status: vote
+ HASH-TABLE-PACKAGE-GENERATORS
Version 7, 8-Dec-88, Released 9-Dec-88
Comments: The test-package-iterator example has the values
from the generator in the wrong order.
Status: passed, Jan 89 X3J13
* HASH-TABLE-PRINTED-REPRESENTATION
Version 2, 8-Jun-88
Comments: Use #S(ARRAY ...), #S(HASH-TABLE...), #S(PATHNAME...)?
Status: need new proposal
! HASH-TABLE-SIZE
Version 1, 20-Mar-89, released 21-Mar-89
+ HASH-TABLE-TESTS
Version 2, 8-Dec-88, Released 8 Dec 88
Status: passed Jan 89 X3J13
+ IEEE-ATAN-BRANCH-CUT
Version 2, 11-Jan-89, Released 11-Jan-89
Status: passed, Jan 89 X3J13
* IGNORE-VARIABLE
Synopsis: default (IGNORE IGNORE)
Version 1, 6-Feb-89
+ IMPORT-SETF-SYMBOL-PACKAGE
Version 5 ??-MAY-87
Status: Passed, 1988?
! IN-PACKAGE-FUNCTIONALITY
Version 4, 12-Dec-88, Released 12-Dec-88
Status: tabled
Version 8, 15-Mar-89, Released 15-Mar-89
Status: ready for vote
+ KEYWORD-ARGUMENT-NAME-PACKAGE
8-NOV-87, Version 8
Status: Passed, 1988?
+ LAST-N
12-MAR-88, Version 2
Status: Passed, 1988?
+ LCM-NO-ARGUMENTS
Version 1, 17 Oct 88, Released 8 Dec 88
Status: passed, Jan 89 X3J13
! LISP-PACKAGE-NAME
Synopsis: change LISP to COMMON-LISP to avoid CLtL confusion
Version 1, 22 Dec 88, Released 11-Jan-89
Status: tabled; version 1 still ready for vote
! LISP-SYMBOL-REDEFINITION
Version 5, 22-Nov-88, Released 8 Dec 88
Comments: Don't like (DEFVAR CAR ...) example
14: Like simpler "Redefining any documented
definition on a symbol in the LISP package -- such as variables,
functions, constants, properties and property-lists, etc -- is
undefined, except for the explicitly allowed cases (e.g. dynamic
binding of variables)."
Status: tabled; version 5 still ready for vote
! LOAD-OBJECTS
Synopsis: Provide a way to allow defstruct/defclass objects in compiled files
Version 3, 9-Mar-89, released 16-Mar-89
Comments: How about MAKE-LOAD-FORM-SAVING-SLOTS?
Status: ready for vote w/ name change?
! LOAD-TRUENAME
Synopsis: Make default pathname for LOAD inside LOAD same?
Version 1, 13-Mar-89, Released 16-Mar-89
Status: ready for vote
! LOCALLY-TOP-LEVEL
Version 2, 16-Mar-89, released 17-Mar-89
Status: ready to vote
! LOOP-AND-DISCREPANCY
Version 1, 15-Mar-89, released 16-Mar-89
status: ready for vote
+ MACRO-FUNCTION-ENVIRONMENT
Version 2, 8-JUN-88
Status: Passed, 1988
* MACRO-SPECIAL-FORMS
Synopsis: macros => implementation-dependent special forms doesn't work
Status: *** NEED PROPOSAL SUBMITTED ****
+ MAKE-PACKAGE-USE-DEFAULT
Version 2, 8 Oct 88, Released 12-Dec-88
Version 3, 16-Mar-89
Status: Passed, Jan 89 X3J13 as amended
! MAKE-STRING-FILL-POINTER
Synopsis: extend MAKE-STRING to take a fill-pointer?
Version 1, 20-Oct-88, released 16-Mar-89
Status: ready for vote
+ MAPPING-DESTRUCTIVE-INTERACTION
Version 2, 09-Jun-88, Released 8 Oct 88
Synopsis: [don't] define interaction of DELETE on MAPCAR'd list.
Status: passed, Jan 89 X3J13
+ NTH-VALUE
Version 4, 8-Dec-88, Released 8 Dec 88
Comment: amended to clarify when index out of range
Version 5, 17-Mar-89
Status: passed, as amended
+ PACKAGE-CLUTTER
Version 6, 12-Dec-88, Released 12-Dec-88
Comments: Accepted, with amendment
Version 7, 17-Mar-89
Status: Passed, Jan 89 X3J13, as amended
+ PACKAGE-DELETION
Version 5, 21 nov 88, Released 8 Dec 88
Comments: Minor glitches? Remove the description of "correctable" error to be signalled and
handled.
Status: passed, Jan 89 X3J13
!+ PACKAGE-FUNCTION-CONSISTENCY
Synopsis: allow strings for package arg everywhere uniformly
Version 2, 12-Jan-89, Released 12-Jan-89
Comment: Accepted MORE-PERMISSIVE with amendments
Version 3, 17-Mar-89, released 17-Mar-89
Status: vote to accept wording as intent of amendment
* PATHNAME-CANONICAL-TYPE
Synopsis: allow canonical :SOURCE-LISP to MAKE-PATHNAME;
require PATHNAME-TYPE to return same?
Version 1, 07-Jul-88
Comments: only add the :TYPE :SOURCE-LISP, not PATHNAME-CANONICAL-TYPE?
Status: => "pathname" committee?
! PATHNAME-COMPONENT-CASE
Version 2, 22-Mar-89, released 22-Mar-89
Status: vote???
! PATHNAME-COMPONENT-VALUE
Version 1, 20-Mar-89, released 21-Mar-89
Status: vote?
* PATHNAME-LOGICAL
Synopsis: add logical pathnames (pathnames for an imaginary portable
file system, which get translated by site-dependent translations into
physical pathnames on an actual file system)
Status: no proposal yet
* PATHNAME-PRINT-READ
Synopsis: Print pathnames like #P"asdf"?
Version 1, 21-Oct-88
Comments: Numerous, pro, con. Print like #S(pathname ...)?
Status: *** NEED NEW VERSION ***
+ PATHNAME-STREAM
Version 6 14-NOV-87
Status: Passed, 1988?
! PATHNAME-SUBDIRECTORY-LIST
Version 4, 22-Mar-89, released 22-mar-89
+ PATHNAME-SYMBOL
Version 5 5-FEB-88
Status: Passed, 1988?
* PATHNAME-SUBDIRECTORY-LIST
Synopsis: How to deal with subdirectory structures in pathname functions
Version 3, 29-Dec-88
Comments: typos and proposed simplifications
Status: *** NEED NEW VERSION ***
* PATHNAME-SYNTAX-ERROR-TIME
Synopsis: when are errors in pathnames detected?
Version 1, 7-Jul-88
Comments: various
Status: need new version? ==> ERRORS-IN-FILE-CHAPTERS?
+ PATHNAME-UNSPECIFIC-COMPONENT
Synopsis: More extensions to :UNSPECIFIC
Version 1, 29-Dec-88, Released 12-Jan-89
Version 2, 17-Mar-89
Status: Passed, Jan 89 X3j13, as amended
+ PEEK-CHAR-READ-CHAR-ECHO
Version 3, 8-Oct-88, Released 8 Oct 88
Synopsis: PEEK-CHAR, READ-CHAR on streams made by MAKE-ECHO-STREAM
Status: Passed, Jan 89 X3J13
* PRETTY-PRINT-INTERFACE
Version 3, 15-Mar-89
Synopsis: standardize interface to prettyprinter
Status: Need new version
+ PRINC-CHARACTER
29-APR-87, Version 2
Status: Passed, 1988?
* PRINT-CIRCLE-SHARED
Synopsis: does *PRINT-CIRCLE* cause shared structure to print with #=?
Status: Not submitted yet ** NEED WRITEUP **
+ PRINT-CIRCLE-STRUCTURE
Version 3, 20 Sep 88, Released 8 Oct 88
Comments: Accepted, with amendment
Version 4, 17-Mar-89
Status: Passed, Jan 89 X3J13, as amended
! PROCLAIM-LEXICAL
Version 9, 8-Dec-88, Released 12-Dec-88
Synopsis: add LEXICAL proclaimation
Comments: lengthy mail; amendments at Jan meeting
Status: tabled, vote on version 9 (w/o amendments)
+ PUSH-EVALUATION-ORDER
Version 5, 25-NOV-87
Status: Passed, 1988?
+ RANGE-OF-COUNT-KEYWORDS
Version 3, 9-Oct-88, Released 14-Oct-88
Status: passed, Jan 89 X3J13
+ RANGE-OF-START-AND-END-PARAMETERS
Version 1, 14-Sep-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
* READ-CASE-SENSITIVITY
Synopsis: Allow readtables to be case sensitive
Comments: use function or keyword?
Status: need new version
* READ-DELIMITED-LIST-EOF
Synopsis: eof in read deliminted list signals an error
Status: awaiting submission
! REAL-NUMBER-TYPE
Synopsis: add REAL = (OR RATIONAL FLOAT) & range
Version 3, 13-Jan-89, released 16-Mar-89
Status: vote?
+ REDUCE-ARGUMENT-EXTRACTION
Version 3 13-FEB-88
Status: Passed, 1988?
! REMF-DESTRUCTION-UNSPECIFIED
Synopsis: Specification of side-effect behavior in CL
Version 4, 29-Nov-88, Released 12-Jan-89
Status: straw vote in favor of this, BarMar will make amendments
Version 6, 17-Mar-89
Status: ready for vote?
+ REQUIRE-PATHNAME-DEFAULTS
Version 6, 9 Dec 88, Released 09 Dec 88
Status: passed, Jan 89 X3j13
+ REST-LIST-ALLOCATION
Version 3, 12-Dec-88, Released 12-Dec-88
Status: proposal MAY-SHARE passed, Jan 89 X3J13
+ RETURN-VALUES-UNSPECIFIED
Version 6, 9 Dec 88, Released 9-Dec-88
Status: passed, Jan 89 X3J13
+ ROOM-DEFAULT-ARGUMENT
Version 1, 12-Sep-88, Released 8 Oct 88
Status: passed, Jan 89 X3J13
! SETF-MULTIPLE-STORE-VARIABLES
Synopsis: Allow multiple "places" in SETF stores
Version 2, 22-Mar-89, released 22-Mar-89
Status: ready for vote?
+ SETF-SUB-METHODS
Version 5, 12-Feb-88, Released 8 Oct 88
Synopsis: careful definition of order inside (SETF (GETF ...) ...)
Status: passed, Jan 89 X3J13
+ SHADOW-ALREADY-PRESENT
Version 4 10-NOV-87
Status: Passed, 1988?
+ SHARPSIGN-PLUS-MINUS-PACKAGE
Version 3 14-NOV-87
Status: Passed, 1988?
+ SPECIAL-TYPE-SHADOWING
Synopsis: intersection of types when proclaimed special has local type
declaration
Version 1, 4-Nov-88, released 11-Jan-89
Status: passed, Jan 89 X3J13
+ STANDARD-INPUT-INITIAL-BINDING
Version 8, 8 Jul 88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
+ STEP-ENVIRONMENT
Version 3, 20-Jun-88, Released 7 Oct 88
Version 4, 17-Mar-89
status: Passed, Jan 89 X3J13, as amended
+ STREAM-ACCESS
Version 2, 30-Nov-88, Released 9 Dec 88
Status: ADD-TYPES-ACCESSORS passed, Jan 89 X3J13
+ SUBSEQ-OUT-OF-BOUNDS
29-MAR-88 Version 2
Status: Passed, 1988?
* SUBTYPEP-ENVIRONMENT
Version 1, 2-Jan-89
Status: ** missing writeup ***
+ SUBTYPEP-TOO-VAGUE
Version 4, 7-Oct-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
+ SYMBOL-MACROLET-DECLARE
Version 2, 9-Dec-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13
!+ SYMBOL-MACROLET-SEMANTICS
Version 5, 30-Nov-88, Released 9 Dec 88
Status: Passed, Jan 89 X3J13
Version 6, 14-Mar-89, released 16-Mar-89
Status: ready for vote
+ TAILP-NIL
Version 5, 9-Dec-88, Released 12-Dec-88
Synopsis: Operation of TAILP given NIL
Status: passed, Jan 89 X3J13
+ TEST-NOT-IF-NOT
Version 3, 1 Dec 88, Released 9 dec
Version 4, 18-Mar-89
Status: Need new version as amended.
! THE-AMBIGUITY
Version 2, 11-Jan-89, Released 11-Jan-89
Comments: typo, sense wrong
Status: tabled, vote on 2
! TIME-ZONE-NON-INTEGER
Version 1, 13-Mar-89, Released 16-Mar-89
Status: ready for vote
+* TYPE-OF-UNDERCONSTRAINED
Version 3, 12-Dec-88, Released 12 Dec 88
Comments: Accepted, with amendments
Version 5, 16-Mar-89
Comments: constraints wrong
Status: ** NEED NEW VERSION ***
! UNDEFINED-VARIABLES-AND-FUNCTIONS
Synopsis: What happens on an undefined function call, unbound variable ref?
Version 1, 29-Nov-88, Released 11-Jan-89
Comments: Lumping SLOT-UNBOUND in with unbound special variables was a mistake,
as SLOT-UNBOUND is an extension mechanism, not only a safety checking
mechanism. Also there were some wording problems. Gabriel and Gregor
are to submit a revised proposal.
No version arrived.
Status: vote on 1?
+ UNREAD-CHAR-AFTER-PEEK-CHAR
Version 2, 2-Dec-88, Released 12-Dec-88
Status: passed, Jan 89 X3J13
+ VARIABLE-LIST-ASYMMETRY
Version 3, 08-Oct-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13
+ WITH-OUTPUT-TO-STRING-APPEND-STYLE
Version 5, 7-JUN-88
Status: Passed, 1988?
! WITH-OPEN-FILE-DOES-NOT-EXIST
Version 1, 17-Mar-89
Status: ready?
∂23-Mar-89 1656 CL-Cleanup-mailer Issue: READ-CASE-SENSITIVITY (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 89 15:56:54 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 564146; Thu 23-Mar-89 18:56:34 EST
Date: Thu, 23 Mar 89 18:56 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: READ-CASE-SENSITIVITY (Version 2)
To: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
cc: CL-Cleanup@sail.stanford.edu, KMP@STONY-BROOK.SCRC.Symbolics.COM,
Masinter.PA@xerox.com, richard%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
In-Reply-To: <2240.8903232311@subnode.aiai.ed.ac.uk>
Message-ID: <890323185605.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Thu, 23 Mar 89 23:11:13 GMT
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
It's very late, but here it is.
Issue: READ-CASE-SENSITIVITY
...
The write-up looks quite good to me. Even though it's late, I plan to
support it.
I prefer option READTABLE-KEYWORDS for two reasons:
(1) your recent arguments about printer issues being simpler that way
(2) the lack of need to add CHAR-INVERT-CASE (which I don't think is very
useful outside of this context).
I do want to mention that I think having an arbitrary function is not as
hard on the printer as you might expect, so I'm not sure READTABLE-FUNCTION
really needs to restrict its inputs. When the system sees an unknown
function, it could iterate over both-case-p characters, calling the function
and figuring out the mappings. Since we're talking about the system, it will
know which chars those are even in the face of international char sets.
It can determine from such a table whether the mapping is one-to-one for
a particular character (so it will know if escaping is needed) as well as
whether the mapping is case-preserving for any given character. However,
even though I think this is possible, I admit it is a pain and probably
just plain not worth the effort so I don't think it's the way to go. Based
on this, I don't really oppose READTABLE-FUNCTION, but I'd much prefer the
simpler READTABLE-KEYWORDS proposal anyway.
Btw, there may be some overlap between this and
PRINT-CASE-PRINT-ESCAPE-INTERACTION. I don't have time to check this to be
sure, but you might want to double-check to avoid last-minute snags.
∂23-Mar-89 1503 CL-Windows-mailer Issue STREAM-DEFINITION-BY-USER (V1)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 23 Mar 89 09:08:32 PST
Received: by ti.com id AA12307; Wed, 22 Mar 89 21:38:08 CST
Received: from Kelvin by tilde id AA27213; Wed, 22 Mar 89 21:21:09 CST
Message-Id: <2815615116-2334006@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 22 Mar 89 21:18:36 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: CL-Cleanup@SAIL.Stanford.edu
Cc: Common-Lisp-Object-System@SAIL.Stanford.edu, CL-Windows@SAIL.Stanford.edu,
Bartley@MIPS.csc.ti.com, Waldrum@Tilde.csc.ti.com, salem@Think.COM
Subject: Issue STREAM-DEFINITION-BY-USER (V1)
Following is a more detailed write-up of the idea of a generic function
I/O interface that allows users to create their own streams. I have put
this in the format of a cleanup proposal because that seems like a good
way of presenting the information, but I realize that the timing isn't
right for including this in the standard now. Hopefully, though, this
can be used as a guideline for implementors to avoid unnecessarily
coming up with different names for the same thing, and after some
experience has been gained, this feature could be considered for
inclusion in a revision of the standard. I wanted to get this in your
hands before the X3J13 meeting in case anyone was interested in
discussing it, but I don't expect any official action to be taken.
Issue: STREAM-DEFINITION-BY-USER
References: CLtL pages 329-332, 378-381, and 384-385.
Related issues: STREAM-INFO, CLOSED-STREAM-FUNCTIONS, STREAM-ACCESS,
STREAM-CAPABILITIES
Category: ADDITION
Edit history: Version 1, 22-Mar-89 by David N. Gray
Status: For discussion and evaluation; not proposed for
inclusion in the standard at this time.
Problem description:
Common Lisp does not provide a standard way for users to define their
own streams for use by the standard I/O functions. This impedes the
development of window systems for Common Lisp because, while there are
standard Common Lisp I/O functions and there are beginning to be
standard window systems, there is no portable way to connect them
together to make a portable Common Lisp window system.
There are also many applications where users might want to define
their own filter streams for doing things like printer device control,
report formatting, character code translation, or
encryption/decryption.
Proposal STREAM-DEFINITION-BY-USER:GENERIC-FUNCTIONS
Overview:
Define a set of generic functions for performing I/O. These functions
will have methods that specialize on the stream argument; they would
be used by the existing I/O functions. Users could write additional
methods for them in order to support their own stream classes.
Define a set of classes to be used as the superclass of a stream class
in order to provide some default methods.
Classes:
The following classes are to be used as super classes of user-defined
stream classes. They are not intended to be directly instantiated; they
just provide places to hang default methods.
FUNDAMENTAL-STREAM [Class]
This class is a subclass of STREAM and of STANDARD-OBJECT. STREAMP
will return true for an instance of any class that includes this. (It
may return true for some other things also.)
FUNDAMENTAL-INPUT-STREAM [Class]
A subclass of FUNDAMENTAL-STREAM. Its inclusion causes INPUT-STREAM-P
to return true.
FUNDAMENTAL-OUTPUT-STREAM [Class]
A subclass of FUNDAMENTAL-STREAM. Its inclusion causes OUTPUT-STREAM-P
to return true. Bi-direction streams may be formed by including both
FUNDAMENTAL-OUTPUT-STREAM and FUNDAMENTAL-INPUT-STREAM.
FUNDAMENTAL-CHARACTER-STREAM [Class]
A subclass of FUNDAMENTAL-STREAM. It provides a method for
STREAM-ELEMENT-TYPE which returns CHARACTER.
FUNDAMENTAL-BINARY-STREAM [Class]
A subclass of FUNDAMENTAL-STREAM. Any instantiable class that
includes this needs to define a method for STREAM-ELEMENT-TYPE.
FUNDAMENTAL-CHARACTER-INPUT-STREAM [Class]
Includes FUNDAMENTAL-INPUT-STREAM and FUNDAMENTAL-CHARACTER-STREAM.
It provides default methods for several generic functions used for
character input.
FUNDAMENTAL-CHARACTER-OUTPUT-STREAM [Class]
Includes FUNDAMENTAL-OUTPUT-STREAM and FUNDAMENTAL-CHARACTER-STREAM.
It provides default methods for several generic functions used for
character output.
FUNDAMENTAL-BINARY-INPUT-STREAM [Class]
Includes FUNDAMENTAL-INPUT-STREAM and FUNDAMENTAL-BINARY-STREAM.
FUNDAMENTAL-BINARY-OUTPUT-STREAM [Class]
Includes FUNDAMENTAL-OUTPUT-STREAM and FUNDAMENTAL-BINARY-STREAM.
Character input:
A character input stream can be created by defining a class that
includes FUNDAMENTAL-CHARACTER-INPUT-STREAM and defining methods for the
generic functions below.
STREAM-READ-CHAR stream [Generic Function]
This reads one character from the stream. It returns either a
character object, or the symbol :EOF if the stream is at end-of-file.
Every subclass of FUNDAMENTAL-CHARACTER-INPUT-STREAM must define a
method for this function.
Note that for all of these generic functions, the stream argument
must be a stream object, not T or NIL.
STREAM-UNREAD-CHAR stream character [Generic Function]
Un-does the last call to STREAM-READ-CHAR, as in UNREAD-CHAR. Returns
NIL. Every subclass of FUNDAMENTAL-CHARACTER-INPUT-STREAM must define
a method for this function.
STREAM-READ-CHAR-NO-HANG stream [Generic Function]
This is used to implement READ-CHAR-NO-HANG. It returns either a
character, or NIL if no input is currently available, or :EOF if
end-of-file is reached. The default method provided by
FUNDAMENTAL-CHARACTER-INPUT-STREAM simply calls STREAM-READ-CHAR; this
is sufficient for file streams, but interactive streams should define
their own method.
STREAM-PEEK-CHAR stream [Generic Function]
Used to implement PEEK-CHAR; this corresponds to peek-type of NIL.
It returns either a character or :EOF. The default method
calls STREAM-READ-CHAR and STREAM-UNREAD-CHAR.
STREAM-LISTEN stream [Generic Function]
Used by LISTEN. Returns true or false. The default method uses
STREAM-READ-CHAR-NO-HANG and STREAM-UNREAD-CHAR. Most streams should
define their own method since it will usually be trivial and will
always be more efficient than the default method.
STREAM-READ-LINE stream [Generic Function]
Used by READ-LINE. A string is returned as the first value. The
second value is true if the string was terminated by end-of-file
instead of the end of a line. The default method uses repeated
calls to STREAM-READ-CHAR.
STREAM-CLEAR-INPUT stream [Generic Function]
Implements CLEAR-INPUT for the stream, returning NIL. The default
method does nothing.
Character output:
A character output stream can be created by defining a class that
includes FUNDAMENTAL-CHARACTER-OUTPUT-STREAM and defining methods for the
generic functions below.
STREAM-WRITE-CHAR stream character [Generic Function]
Writes character to the stream and returns the character. Every
subclass of FUNDAMENTAL-CHARACTER-OUTPUT-STREAM must have a method
defined for this function.
STREAM-LINE-COLUMN stream [Generic Function]
This function returns the column number where the next character
will be written, or NIL if that is not meaningful for this stream.
The first column on a line is numbered 0. This function is used in
the implementation of PPRINT and the FORMAT ~T directive. For every
character output stream class that is defined, a method must be
defined for this function, although it is permissible for it to
always return NIL.
STREAM-START-LINE-P stream [Generic Function]
This is a predicate which returns T if the stream is positioned at the
beginning of a line, else NIL. It is permissible to always return
NIL. This is used in the implementation of FRESH-LINE. Note that
while a value of 0 from STREAM-LINE-COLUMN also indicates the
beginning of a line, there are cases where STREAM-START-LINE-P can be
meaningfully implemented although STREAM-LINE-COLUMN can't be. For
example, for a window using variable-width characters, the column
number isn't very meaningful, but the beginning of the line does have
a clear meaning. The default method for STREAM-START-LINE-P on class
FUNDAMENTAL-CHARACTER-OUTPUT-STREAM uses STREAM-LINE-COLUMN, so if
that is defined to return NIL, then a method should be provided for
either STREAM-START-LINE-P or STREAM-FRESH-LINE.
STREAM-WRITE-STRING stream string &optional start end [Generic Function]
This is used by WRITE-STRING. It writes the string to the stream,
optionally delimited by start and end, which default to 0 and NIL.
The string argument is returned. The default method provided by
FUNDAMENTAL-CHARACTER-OUTPUT-STREAM uses repeated calls to
STREAM-WRITE-CHAR.
STREAM-TERPRI stream [Generic Function]
Writes an end of line, as for TERPRI. Returns NIL. The default
method does (STREAM-WRITE-CHAR stream #\NEWLINE).
STREAM-FRESH-LINE stream [Generic Function]
Used by FRESH-LINE. The default method uses STREAM-START-LINE-P and
STREAM-TERPRI.
STREAM-FINISH-OUTPUT stream [Generic Function]
Implements FINISH-OUTPUT. The default method does nothing.
STREAM-FORCE-OUTPUT stream [Generic Function]
Implements FORCE-OUTPUT. The default method does nothing.
STREAM-CLEAR-OUTPUT stream [Generic Function]
Implements CLEAR-OUTPUT. The default method does nothing.
STREAM-ADVANCE-TO-COLUMN stream column [Generic Function]
Writes enough blank space so that the next character will be written
at the specified column. Returns true if the operation is
successful, or NIL if it is not supported for this stream.
This is intended for use by by PPRINT and FORMAT ~T. The default
method uses STREAM-LINE-COLUMN and repeated calls to
STREAM-WRITE-CHAR with a #\SPACE character; it returns NIL if
STREAM-LINE-COLUMN returns NIL.
Other functions:
CLOSE stream &key abort [Generic Function]
The existing function CLOSE is redefined to be a generic function, but
otherwise behaves the same. The default method provided by class
FUNDAMENTAL-STREAM sets a flag for OPEN-STREAM-P. The value returned
by CLOSE will be as specified by the issue CLOSED-STREAM-OPERATIONS.
OPEN-STREAM-P stream [Generic Function]
This function [from proposal STREAM-ACCESS] is made generic. A
default method is provided by class FUNDAMENTAL-STREAM which returns
true if CLOSE has not been called on the stream.
STREAMP object [Generic Function]
INPUT-STREAM-P stream [Generic Function]
OUTPUT-STREAM-P stream [Generic Function]
These three existing predicates may optionally be implemented as
generic functions for implementations that want to permit users to
define streams that are not STANDARD-OBJECTs. Normally, the default
methods provided by classes FUNDAMENTAL-INPUT-STREAM and
FUNDAMENTAL-OUTPUT-STREAM are sufficient. Note that, for example,
(INPUT-STREAM-P x) is not equivalent to (TYPEP x
'FUNDAMENTAL-INPUT-STREAM) because implementations may have
additional ways of defining their own streams even if they don't
make that visible by making these predicates generic.
STREAM-ELEMENT-TYPE stream [Generic Function]
This existing function is made generic, but otherwise behaves the
same. Class FUNDAMENTAL-CHARACTER-STREAM provides a default method
which returns CHARACTER.
PATHNAME and TRUENAME are also permitted to be implemented as generic
functions. There is no default method since these are not valid for
all streams.
Binary streams:
Binary streams can be created by defining a class that includes either
FUNDAMENTAL-BINARY-INPUT-STREAM or FUNDAMENTAL-BINARY-OUTPUT-STREAM
(or both) and defining a method for STREAM-ELEMENT-TYPE and for one or
both of the following generic functions.
STREAM-READ-BYTE stream [Generic Function]
Used by READ-BYTE; returns either an integer, or the symbol :EOF if the
stream is at end-of-file.
STREAM-WRITE-BYTE stream integer [Generic Function]
Implements WRITE-BYTE; writes the integer to the stream and returns
the integer as the result.
Rationale:
The existing I/O functions cannot be made generic because, in nearly
every case, the stream argument is optional, and therefore cannot be
specialized. Therefore, it is necessary to define a lower-level
generic function to be used by the existing function. It also isn't
appropriate to specialize on the second argument of PRINT-OBJECT because
it is a higher-level function -- even when the first argument is a
character or a string, it needs to format it in accordance with
*PRINT-ESCAPE*.
In order to make the meaning as obvious as possible, the names of the
generic functions have been formed by prefixing "STREAM-" to the
corresponding non-generic function.
Having the generic input functions just return :EOF at end-of-file, with
the higher-level functions handling the eof-error-p and eof-value
arguments, simplifies the generic function interface and makes it more
efficient by not needing to pass through those arguments. Note that the
functions that use this convention can only return a character or
integer as a stream element, so there is no possibility of ambiguity.
Functions STREAM-LINE-COLUMN, STREAM-START-LINE-P, and
STREAM-ADVANCE-TO-COLUMN may appear to be a reincarnation of the
defeated proposal STREAM-INFO, but the motivation here is different.
This interface needs to be defined if user-defined streams are to be
able to be used by PPRINT and FORMAT ~T, which could be viewed as a
separate question from whether the user can call then on
system-defined streams.
Current practice:
No one currently supports exactly this proposal, but this is very
similar to the stream interface used in CLUE.
On descendants of the MIT Lisp Machine, streams can be implemented
by users as either flavors, with methods to accept the various
messages corresponding to the I/O operations, or as functions, which
take a message keyword as their first argument.
Examples:
;;;; Here is an example of how the default methods could be
;;;; implemented (omitting the most trivial ones):
(defmethod STREAM-PEEK-CHAR ((stream fundamental-character-input-stream))
(let ((character (stream-read-char stream)))
(unless (eq character :eof)
(stream-unread-char stream character))
character))
(defmethod STREAM-LISTEN ((stream fundamental-character-input-stream))
(let ((char (stream-read-char-no-hang stream)))
(and (not (null char))
(not (eq char :eof))
(progn (stream-unread-char stream char) t))))
(defmethod STREAM-READ-LINE ((stream fundamental-character-input-stream))
(let ((line (make-array 64 :element-type 'string-char
:fill-pointer 0 :adjustable t)))
(loop (let ((character (stream-read-char stream)))
(if (eq character :eof)
(return (values line t))
(if (eql character #\newline)
(return (values line nil))
(vector-push-extend character line)))))))
(defmethod STREAM-START-LINE-P ((stream fundamental-character-output-stream))
(equal (stream-line-column stream) 0))
(defmethod STREAM-WRITE-STRING ((stream fundamental-character-output-stream)
string &optional (start 0)
(end (length string)))
(do ((i start (1+ i)))
((>= i end) string)
(stream-write-char stream (char string i))))
(defmethod STREAM-TERPRI ((stream fundamental-character-output-stream))
(stream-write-char stream #\newline)
nil)
(defmethod STREAM-FRESH-LINE ((stream fundamental-character-output-stream))
(if (stream-start-line-p stream)
nil
(progn (stream-terpri stream) t)))
(defmethod STREAM-ADVANCE-TO-COLUMN ((stream fundamental-character-output-stream)
column)
(let ((current (stream-line-column stream)))
(unless (null current)
(dotimes (i (- current column) t)
(stream-write-char stream #\space)))))
(defmethod INPUT-STREAM-P ((stream fundamental-input-stream)) t)
(defmethod INPUT-STREAM-P ((stream fundamental-output-stream))
;; allow the two classes to be mixed in either order
(typep stream 'fundamental-input-stream))
(defmethod OUTPUT-STREAM-P ((stream fundamental-output-stream)) t)
(defmethod OUTPUT-STREAM-P ((stream fundamental-input-stream))
(typep stream 'fundamental-output-stream))
;;;; Following is an example of how the existing I/O functions could
;;;; be implemented using standard Common Lisp and the generic
;;;; functions specified above. The standard functions being defined
;;;; are in upper case.
;; Internal helper functions
(proclaim '(inline decode-read-arg decode-print-arg check-for-eof))
(defun decode-read-arg (arg)
(cond ((null arg) *standard-input*)
((eq arg t) *terminal-io*)
(t arg)))
(defun decode-print-arg (arg)
(cond ((null arg) *standard-output*)
((eq arg t) *terminal-io*)
(t arg)))
(defun check-for-eof (value stream eof-errorp eof-value)
(if (eq value :eof)
(report-eof stream eof-errorp eof-value)
value))
(defun report-eof (stream eof-errorp eof-value)
(if eof-errorp
(error 'end-of-file :stream stream)
eof-value))
;;; Common Lisp input functions
(defun READ-CHAR (&optional input-stream (eof-errorp t) eof-value recursive-p)
(declare (ignore recursive-p)) ; a mistake in CLtL?
(let ((stream (decode-read-arg input-stream)))
(check-for-eof (stream-read-char stream) stream eof-errorp eof-value)))
(defun PEEK-CHAR (&optional peek-type input-stream (eof-errorp t)
eof-value recursive-p)
(declare (ignore recursive-p))
(let ((stream (decode-read-arg input-stream)))
(if (null peek-type)
(check-for-eof (stream-peek-char stream) stream eof-errorp eof-value)
(loop
(let ((value (stream-peek-char stream)))
(if (eq value :eof)
(return (report-eof stream eof-errorp eof-value))
(if (if (eq peek-type t)
(not (member value '(#\space #\tab #\newline
#\page #\return #\linefeed)))
(char= peek-type value))
(return value)
(stream-read-char stream))))))))
(defun UNREAD-CHAR (character &optional input-stream)
(stream-unread-char (decode-read-arg input-stream) character))
(defun LISTEN (&optional input-stream)
(stream-listen (decode-read-arg input-stream)))
(defun READ-LINE (&optional input-stream (eof-error-p t)
eof-value recursive-p)
(declare (ignore recursive-p))
(let ((stream (decode-read-arg input-stream)))
(multiple-value-bind (string eofp)
(stream-read-line stream)
(if eofp
(if (= (length string) 0)
(report-eof stream eof-error-p eof-value)
(values string t))
(values string nil)))))
(defun CLEAR-INPUT (&optional input-stream)
(stream-clear-input (decode-read-arg input-stream)))
(defun READ-CHAR-NO-HANG (&optional input-stream (eof-errorp t)
eof-value recursive-p)
(declare (ignore recursive-p))
(let ((stream (decode-read-arg input-stream)))
(check-for-eof (stream-read-char-no-hang stream)
stream eof-errorp eof-value)))
;;; Common Lisp output functions
(defun WRITE-CHAR (character &optional output-stream)
(stream-write-char (decode-print-arg output-stream) character))
(defun FRESH-LINE (&optional output-stream)
(stream-fresh-line (decode-print-arg output-stream)))
(defun TERPRI (&optional output-stream)
(stream-terpri (decode-print-arg output-stream)))
(defun WRITE-STRING (string &optional output-stream &key (start 0) end)
(stream-write-string (decode-print-arg output-stream) string start end))
(defun WRITE-LINE (string &optional output-stream &key (start 0) end)
(let ((stream (decode-print-arg output-stream)))
(stream-write-string stream string start end)
(stream-terpri stream)
string))
(defun FORCE-OUTPUT (&optional stream)
(stream-force-output (decode-print-arg stream)))
(defun FINISH-OUTPUT (&optional stream)
(stream-finish-output (decode-print-arg stream)))
(defun CLEAR-OUTPUT (&optional stream)
(stream-clear-output (decode-print-arg stream)))
;;; Binary streams
(defun READ-BYTE (binary-input-stream &optional (eof-errorp t) eof-value)
(check-for-eof (stream-read-byte binary-input-stream)
binary-input-stream eof-errorp eof-value))
(defun WRITE-BYTE (integer binary-output-stream)
(stream-write-byte binary-output-stream integer))
;;; String streams
(defclass string-input-stream (fundamental-character-input-stream)
((string :initarg :string :type string)
(index :initarg :start :type fixnum)
(end :initarg :end :type fixnum)
))
(defun MAKE-STRING-INPUT-STREAM (string &optional (start 0) end)
(make-instance 'string-input-stream :string string
:start start :end (or end (length string))))
(defmethod stream-read-char ((stream string-input-stream))
(with-slots (index end string) stream
(if (>= index end)
:eof
(prog1 (char string index)
(incf index)))))
(defmethod stream-unread-char ((stream string-input-stream) character)
(with-slots (index end string) stream
(decf index)
(assert (eql (char string index) character))
nil))
(defmethod stream-read-line ((stream string-input-stream))
(with-slots (index end string) stream
(let* ((endline (position #\newline string :start index :end end))
(line (subseq string index endline)))
(if endline
(progn (setq index (1+ endline))
(values line nil))
(progn (setq index end)
(values line t))))))
(defclass string-output-stream (fundamental-character-output-stream)
((string :initform nil :initarg :string)))
(defun MAKE-STRING-OUTPUT-STREAM ()
(make-instance 'string-output-stream))
(defun GET-OUTPUT-STREAM-STRING (stream)
(with-slots (string) stream
(if (null string)
""
(prog1 string (setq string nil)))))
(defmethod stream-write-char ((stream string-output-stream) character)
(with-slots (string) stream
(when (null string)
(setq string (make-array 64. :element-type 'string-char
:fill-pointer 0 :adjustable t)))
(vector-push-extend character string)
character))
(defmethod stream-line-column ((stream string-output-stream))
(with-slots (string) stream
(if (null string)
0
(let ((nx (position #\newline string :from-end t)))
(if (null nx)
(length string)
(- (length string) nx 1))
))))
Cost to Implementors:
Given that CLOS is supported, adding the above generic functions and
methods is easy, since most of the code is included in the examples
above. The hard part would be re-writing existing I/O functionality in
terms of methods on these new generic functions. That could be
simplified if methods can be defined to forward the operations to the
old representation of streams. For a new implementation, the cost could
be zero since an approach similar to this would likely be used anyway.
Cost to Users:
None; this is an upward-compatible addition. Users won't even
need to know anything about this unless they actually need this feature.
Cost of non-adoption:
Development of portable I/O extensions will be discouraged.
Performance impact:
This shouldn't affect performance of new implementations (assuming an
efficient CLOS implementation), but it could slow down I/O if it were
clumsily grafted on top of an existing implementation.
Benefits:
A broader domain of programs that can be written portably.
Esthetics:
This seems to be a simple, straight-forward approach.
Discussion:
This proposal incorporates suggestions made by several people in
response to an earlier outline. So far, no one has expressed opposition
to the concept. There are some differences of opinion about whether
certain operations should have default methods or required methods:
STREAM-LISTEN, STREAM-READ-CHAR-NO-HANG, STREAM-LINE-COLUMN,
and STREAM-START-LINE-P.
An experimental prototype of this has been successfully implemented on
the Explorer.
This proposal does not provide sufficient capability to implement
forwarding streams such as for MAKE-SYNONYM-STREAM,
MAKE-BROADCAST-STREAM, MAKE-CONCATENATED-STREAM, MAKE-TWO-WAY-STREAM, or
MAKE-ECHO-STREAM. The generic function approach does not lend itself as
well to that as a message passing model where the intermediary does not
need to know what all the possible messages are. A possible way of
extending it for that would be to define a class
(defclass stream-generic-function (standard-generic-function) ())
to be used as the :generic-function-class option for all of the I/O
generic functions. This would then permit doing something like
(defmethod no-applicable-method ((gfun stream-generic-function) &rest args)
(if (streamp (first args))
(apply #'stream-operation-not-handled (first args) gfun (rest args))
(call-next-method)))
where stream-operation-not-handled is a generic function whose default
method signals an error, but forwarding streams can define methods that
will create a method to handle the unexpected operation. (Perhaps
NO-APPLICABLE-METHOD should be changed to take two required arguments
since all generic functions need at least one required argument, and
that would make it unnecessary to define a new generic function class
just to be able to write this one method.)
Another thing that is not addressed here is a way to cause an instance
of a user-defined stream class to be created from a call to the OPEN
function. That should be part of a separate issue for generic functions
on pathnames. If that capability were available, then PATHNAME and
TRUENAME should be required to be generic functions.
An earlier draft defined just two classes, FUNDAMENTAL-INPUT-STREAM and
FUNDAMENTAL-OUTPUT-STREAM, that were used for both character and binary
streams. It isn't clear whether that simple approach is sufficient or
whether the larger set of classes is really needed.
∂23-Mar-89 1813 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 2)
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 23 Mar 89 18:13:26 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
id AA08865; Thu, 23 Mar 89 18:15:31 PST
Received: from denali.sun.com by snail.Sun.COM (4.1/SMI-4.1)
id AA14491; Thu, 23 Mar 89 18:11:37 PST
Received: from localhost by denali.sun.com (3.2/SMI-3.2)
id AA04765; Thu, 23 Mar 89 18:14:55 PST
Message-Id: <8903240214.AA04765@denali.sun.com>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
Cc: CL-Cleanup@sail.stanford.edu
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 2)
In-Reply-To: Your message of Thu, 23 Mar 89 18:56:00 -0500;
<890323185605.7.KMP@BOBOLINK.SCRC.Symbolics.COM> .
Date: Thu, 23 Mar 89 18:14:53 PST
From: peck@Sun.COM
>(2) the lack of need to add CHAR-INVERT-CASE (which I don't think is very
> useful outside of this context).
I guess i don't see how this is useful even in this context.
Is this a Symbolics'ism?
If :preserve is an option, why would someone want :INVERT?
dOES SOMEONE THINK :invert IS EASIER TO TYPE THAN eSCAPES or vERTICAL-bARS?
dO YOU HAVE files WRITTEN WITH :invert?
How about throwing out :INVERT *and* CHAR-INVERT-CASE?
Which of READTABLE-KEYWORDS or READTABLE-FUNCTIONS would you prefer then?
[given a sufficiently powerful Emacs that can escape the chars before
passing them to the Lisp reader, does any of this matter to X3J13?]
While we are busy trying to be KSR33 compatible, the rest of the world
may zoom on by. The Japanese won't be interested in much of this code.
Oops, sorry, that is not a cleanup issue.
∂23-Mar-89 1518 CL-Cleanup-mailer Issue: DIRECTORY-DOES-TOO-MUCH
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 23 Mar 89 15:13:59 PST
Received: from pitney-bowes ([192.9.200.50]) by heavens-gate.lucid.com id AA03822g; Thu, 23 Mar 89 15:08:24 PST
Received: by pitney-bowes id AA26773g; Thu, 23 Mar 89 15:06:47 PST
Date: Thu, 23 Mar 89 15:06:47 PST
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8903232306.AA26773@pitney-bowes>
To: CL-Cleanup@SAIL.Stanford.edu
Subject: Issue: DIRECTORY-DOES-TOO-MUCH
While thinking about pathnames, I was reminded of this possible small
addition:
Issue: DIRECTORY-DOES-TOO-MUCH
Forum: Cleanup
References: DIRECTORY (p427)
Related issues: NONE
Category: ADDITION
Edit history: 14-Mar-89, Version 1 by James L. McDonald
Status: For Internal Discussion
Problem description:
According to CLtL, DIRECTORY returns a list of truenames, "one for
each file in the file system that matches the given pathname".
The problem is that sometimes one wants the truenames for just one
or a few of the files that match, or one wants to interleave
processing of each file as it is found, to minimize the start-up
time when processing large directories.
Proposal (DIRECTORY-DOES-TOO-MUCH:ADD-GENERATOR):
Add the function DIRECTORY-GENERATOR which would accept the same
argument spectrum as DIRECTORY and return a function which, when
successively applied, would yield each of truenames in the list
of truenames that DIRECTORY would have returned, and then NIL to
indicate no more files are available.
Examples:
This example illustrates how wasted effort could be avoided:
(DEFUN FIND-DEFINING-FILE (MUMBLE)
(LET ((FN (DIRECTORY-GENERATOR "/moby-dir/*.lisp")))
(DO ((TRUENAME (FUNCALL FN) (FUNCALL FN)))
((NULL TRUENAME)
NIL)
(WHEN (FILE-DEFINES-P TRUENAME MUMBLE)
(RETURN TRUENAME)))))
This example shows how a system with some distributed processing
ability might interleave file accessing and processing:
(DEFUN COMPILE-WORLD ()
(LET ((FN (DIRECTORY-GENERATOR "/moby-dir/*.lisp")))
(DO ((TRUENAME (FUNCALL FN) (FUNCALL FN)))
((NULL TRUENAME)
NIL)
(INITIATE-DISTRIBUTED-COMPILATION TRUENAME))))
Test Cases:
This should return true for all arguments, assuming that during
the execution of the test files are not added to or removed from
the file-system being accessed.
(DEFUN FOO (X)
(OR (NOT (PATHNAMEP X))
(NULL (SET-EXCLUSIVE-OR ; why doesn't CL have SET-EQUAL ?
(DIRECTORY X)
(LET ((FN (DIRECTORY-GENERATOR X))
(DIR '()))
(DO ((TRUENAME (FUNCALL FN) (FUNCALL FN)))
((NULL TRUENAME)
(REVERSE DIR))
(PUSH TRUENAME DIR)))))))
Rationale:
This seems simple, useful, and uncontroversial. For many file
systems, it provides a CL primitive that maps more directly to
underlying OS primitives.
Current practice:
Lucid Common Lisp has always implemented DIRECTORY in much this way.
Cost to Implementors:
Minimal. Any port could come into compliance by defining
DIRECTORY-GENERATOR as:
(DEFUN DIRECTORY-GENERATOR (X)
(LET ((DIR (DIRECTORY X)))
#'(LAMBDA () (POP DIR))))
Implementing it more directly is probably either a fairly small task
or clearly impossible. Either way, not much work.
Cost to Users:
None.
Cost of non-adoption:
DIRECTORY continues to be needlessly inefficient in some cases.
Performance impact:
Some programs may run faster or reduce the maximum delay visible
to users.
Benefits:
See performance impact.
Esthetics:
Minor.
Discussion:
The test case presumes truenames are generated in the same order
that DIRECTORY now lists them. This is a minor restriction but
would fail for systems that explicitly sort their results or file
systems that randomly reorder directories (e.g. on every access).
Set equivalence is probably just as good a test if anyone cares.
∂23-Mar-89 1534 CL-Cleanup-mailer Re: Issue: GENSYM-NAME-STICKINESS (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Mar 89 15:32:17 PST
Received: from Semillon.ms by ArpaGateway.ms ; 23 MAR 89 12:59:59 PST
Date: 23 Mar 89 12:59 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: GENSYM-NAME-STICKINESS (Version 3)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Tue, 21 Mar 89 11:45 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890323-125959-5425@Xerox>
please release to X3J13; thanks.
∂23-Mar-89 2050 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 89 20:50:36 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 564301; Thu 23-Mar-89 23:49:43 EST
Date: Thu, 23 Mar 89 23:49 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 2)
To: peck@Sun.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM,
jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK,
CL-Cleanup@sail.stanford.edu
In-Reply-To: <8903240214.AA04765@denali.sun.com>
Message-ID: <890323234914.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
I shouldn't even be bothering to reply to a message like this at this late
date. I have better things to be doing. However, I'll let this be my one
for the day -- if only to lend a little support to Jeff because I think
the tone of ridicule in your message to be somewhat out of line. In spite
of this, I've tried to keep my tone constructive and to answer your questions
in earnest.
Date: Thu, 23 Mar 89 18:14:53 PST
From: peck@Sun.COM
>(2) the lack of need to add CHAR-INVERT-CASE (which I don't think is very
> useful outside of this context).
I guess i don't see how this is useful even in this context.
Is this a Symbolics'ism?
I didn't find this remark to be particularly professional. I wish we could
just avoid that kind of thing.
The answer happens to be "no", it is not something we use here.
It's something Jeff dreamed up, I guess.
I didn't oppose it because I'm not in the habit of out-of-hand opposing
things just because I personally don't see as having practical value. I
think the real acid test of willingness to cooperate on compatibility is
a willingness to tolerate noops and useless features because they turn
out to be useful to someone else.
My offhand guess is that it is in fact useful in some implementations.
Your example below which uses mixed case doesn't give it fair play.
Suppose there's an intermediate situation where you implement an embedded
language in which you can only use all-uppercase or all-lowercase names.
Suppose you want the all-lowercase names to be the ones that correspond to
Lisp names. I don't happen to want to do that, but it seemed plausible to
me that someone might -- and it might be what Jeff had in mind.
The cost of the feature he's asking for is very small, especially if you
consider the hair someone would have to go through to write that embedded
language portably if you didn't offer the feature.
If :preserve is an option, why would someone want :INVERT?
dOES SOMEONE THINK :invert IS EASIER TO TYPE THAN eSCAPES or vERTICAL-bARS?
dO YOU HAVE files WRITTEN WITH :invert?
How about throwing out :INVERT *and* CHAR-INVERT-CASE?
How about being civil and first asking Jeff politely why he wanted the feature.
Which of READTABLE-KEYWORDS or READTABLE-FUNCTIONS would you prefer then?
It doesn't affect my vote. I still prefer the former over the latter, and I
still don't seriously oppose the latter.
[given a sufficiently powerful Emacs that can escape the chars before
passing them to the Lisp reader, does any of this matter to X3J13?]
The issue is not text editors. Given a sufficiently powerful Emacs, you could
code in C and still pass your information off to Lisp. ``It's only software''
as they say. The issue is that the language must be defined as the interface
between the outside world and Lisp. The language is exactly what you can expect
to be held constant as you move from system to system, text editor to text editor.
Either the language handles case conversion or the text editor does.
Jeff is suggesting that he would like the text editor to do so. I don't happen
to want to do that, but I can't deny that he is making a fair request.
While we are busy trying to be KSR33 compatible, the rest of the world
may zoom on by.
I have never used a KSR33. I think I've seen one. I have no particular desire
to be compatible with one. I can't imagine why this remark is relevant here.
The Japanese won't be interested in much of this code.
Oops, sorry, that is not a cleanup issue.
In my mind, it is not our purpose to design a language suitable for the Japanese.
It is our purpose to design a language suitable for us, and to try to listen
to the Japanese (and anyone else) about problems what we do might cause. While
this feature might not be interesting to them, it's hard to see how it could
cause them any problem.
The Japanese will have their opportunity to speak, and I will pay close attention.
If you say what you personally want and why, sans ridicule, I will try to pay
close attention to that, too.
∂23-Mar-89 2232 CL-Cleanup-mailer Issue: DIRECTORY-DOES-TOO-MUCH
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 89 22:32:44 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 564358; Fri 24-Mar-89 01:32:03 EST
Date: Fri, 24 Mar 89 01:31 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DIRECTORY-DOES-TOO-MUCH
To: jlm@lucid.com
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8903232306.AA26773@pitney-bowes>
Message-ID: <890324013136.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
I don't oppose your proposal, but I have some non-preemptive remarks
that you might want to consider factoring into a revision if you have
time to pursue the issue. (I really don't know how much I believe these
suggestions, but they occurred to me and I thought I would share them.)
Criticisms:
- I think the name DIRECTORY-GENERATOR is a bit long
and not startlingly perspicuous.
- I think that returning a function means that some common
cases will seem unduly complicated because of the need to
FUNCALL the result to turn it into a useable form.
These are not fatal flaws, but they drive the following suggestions:
You might want an interface like
(DIRECTORY-1 pathname) => pathname-or-nil, function-or-nil
[Actually, it's clear that first return value has to be NIL.
The second return value doesn't have to be NIL -- it could be
a function which returns NIL when called, but people might want
to optimize that case.]
The name is by analogy with MACROEXPAND-1. You'd get a useful
primary value and some more-p information in the secondary value
that you could discard if you didn't want.
The really nice feature of the data flow is, of course, that you can
directly use the single return value without further fuss or funcall.
You might even want to allow it to taken an optional argument saying
you didn't want the second return value (i.e., that NIL was ok) to
avoid consing.
(DIRECTORY-1 pathname NIL) => pathname-or-nil, nil
Alternatively, or additionally, you might want to think about
extending DIRECTORY to take a keyword requesting the indicated
functionality. e.g.,
(DIRECTORY pathname :COUNT 1)
might want to return just the first pathname, presumably as a list
to be compatible with the normal style of DIRECTORY, and to generalize
nicely to :COUNT arguments like 0 or 2.
If this were an alternative to DIRECTORY-1, it could also return a
second return value which was the stepper function (or NIL if none).
If this were just in addition to DIRECTORY-1, then it could arguably
not bother with the second return value and make you call DIRECTORY-1
if you needed that much power.
∂24-Mar-89 0745 CL-Cleanup-mailer Re: Issue: DIRECTORY-DOES-TOO-MUCH
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 24 Mar 89 07:44:59 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa08010; 24 Mar 89 10:29 EST
Received: from draper.com by RELAY.CS.NET id aa00637; 24 Mar 89 10:25 EST
Date: Fri, 24 Mar 89 09:17 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Issue: DIRECTORY-DOES-TOO-MUCH
To: cl-cleanup@SAIL.STANFORD.EDU
X-VMS-To: CL-CLEANUP,SEB1525
> Date: Fri, 24 Mar 89 01:31 EST
> From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.COM>
> Subject: Issue: DIRECTORY-DOES-TOO-MUCH
> To: jlm@lucid.COM
>
> You might want an interface like
>
> (DIRECTORY-1 pathname) => pathname-or-nil, function-or-nil
>
> [Actually, it's clear that first return value has to be NIL.
> The second return value doesn't have to be NIL -- it could be
> a function which returns NIL when called, but people might want
> to optimize that case.]
>
[...]
>
> You might even want to allow it to taken an optional argument saying
> you didn't want the second return value (i.e., that NIL was ok) to
> avoid consing.
>
> (DIRECTORY-1 pathname NIL) => pathname-or-nil, nil
Now that's a slippery slope. If we start allowing functions to take an
optional argument telling them how many values {not} to return, where do
we stop? In any case, it's the job of the compiler and its many optimizers,
in most cases, to determine when and if it is possible/feasible/desirable to
generate code that avoids returning unused values.
Plus, which is more painful - a few extra conses, or the directory lookup
in the first place? (Answer: implementation-dependent.)
∂24-Mar-89 0807 CL-Cleanup-mailer Meeting 1 hour before plenary session?
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 24 Mar 89 08:07:41 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 325694; Fri 24-Mar-89 11:06:59 EST
Date: Fri, 24 Mar 89 11:07 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Meeting 1 hour before plenary session?
To: masinter.pa@XEROX.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <890323-122134-5313@Xerox>
Message-ID: <19890324160717.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 23 Mar 89 12:19 PST
From: masinter.pa@Xerox.COM
I'm back near a mailbox. Can we get together an hour before the main
session to go over the cleanup report agenda? I want to order the cleanup
issues so that we handle the "important" ones first. I roughly think that
means:
a) fix the cleanups that were previously broken
b) clarifications
c) changes
c) additions
within each category, order mainly by age: handle oldest issues first. But
then, there are some of these that are more 'important' that we'll want to
mess up the order.
This sounds good. Also we may want to move related issues next to each
other (although the pathname issues will be next to each other in alphabetical
order).
I plan to put together a proposal for dealing with these over the next few
days and will mail it out, but you might want to come prepared with your
own list of "things that are critically important to get voted on this
meeting".
It's too late to mail any more things out, at least for me. I hope not to
work this weekend.
∂24-Mar-89 1015 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 2)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 24 Mar 89 10:14:11 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa03563; 24 Mar 89 16:30 GMT
Date: Fri, 24 Mar 89 16:32:37 GMT
Message-Id: <3273.8903241632@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 2)
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, peck@sun.com
Cc: CL-Cleanup@sail.stanford.edu
> How about throwing out :INVERT *and* CHAR-INVERT-CASE?
> Which of READTABLE-KEYWORDS or READTABLE-FUNCTIONS would you prefer then?
Probably FUNCTIONS. But then for a random function (e.g., a
CHAR-INVERT-CASE defined by me), I'd want output to leave case
intact, without escapes.
-- Jeff
∂24-Mar-89 1024 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 2)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 24 Mar 89 10:24:32 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa03359; 24 Mar 89 15:59 GMT
Date: Fri, 24 Mar 89 16:01:12 GMT
Message-Id: <2935.8903241601@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 2)
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, peck@sun.com
Cc: CL-Cleanup@sail.stanford.edu
I do not understand why this proposal causes such confusion. Perhaps
my writing isn't as clear as it might be, but I don't think it's that
bad.
> >(2) the lack of need to add CHAR-INVERT-CASE (which I don't think is very
> > useful outside of this context).
> I guess i don't see how this is useful even in this context.
> Is this a Symbolics'ism?
No.
> If :preserve is an option, why would someone want :INVERT?
It's in the rationale. If I set the readtable to :PRESERVE and
then want to use it to keep case distinctions in my Lisp code --
some people do want to do this -- I may also want to type the names
of symbols in the "LISP" package in lower case rather than upper.
There are two ways to get that: change the internal case to lower
or invert what's typed in.
> dOES SOMEONE THINK :invert IS EASIER TO TYPE THAN eSCAPES or vERTICAL-bARS?
> dO YOU HAVE files WRITTEN WITH :invert?
No, someone thinks (car x) is nicer than (CAR x).
One may well have files written in :INVERT. Any file that uses only
lower case for Lisp code relies on case-insensitivity to convert the
names to upper case. Those same files could just as well be read
with :INVERT.
> [given a sufficiently powerful Emacs that can escape the chars before
> passing them to the Lisp reader, does any of this matter to X3J13?]
Given sufficiently powerful tools other than Lisp, why does anything
matter to X3J13?
Besides, is Emacs going to read all of my streams for me?
> While we are busy trying to be KSR33 compatible, the rest of the world
> may zoom on by. The Japanese won't be interested in much of this code.
> Oops, sorry, that is not a cleanup issue.
The only thing in any of this that's could reasonably be called KSR33
compatible is the choice of upper case for the internal preferred
case. This proposal is trying to make that choice less significant.
-- Jeff
∂24-Mar-89 1344 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 2)
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 24 Mar 89 13:44:38 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
id AA00368; Fri, 24 Mar 89 13:46:08 PST
Received: from denali.sun.com by snail.Sun.COM (4.1/SMI-4.1)
id AA19874; Fri, 24 Mar 89 13:42:14 PST
Received: from localhost by denali.sun.com (3.2/SMI-3.2)
id AA07858; Fri, 24 Mar 89 13:45:29 PST
Message-Id: <8903242145.AA07858@denali.sun.com>
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Cc: CL-Cleanup@sail.stanford.edu
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 2)
In-Reply-To: Your message of Fri, 24 Mar 89 16:01:12 +0000;
<2935.8903241601@subnode.aiai.ed.ac.uk> .
Date: Fri, 24 Mar 89 13:45:27 PST
From: peck@Sun.COM
Assuming that my confusion about :invert is resolved offline,
I have another, more positive suggestion for getting CommonLisp
into the case-sensitive world:
The biggest block that i've found to writting portable code
in the mixed/preserve case world is those times when you want
intern a symbol from a string. If the string is either hard-coded
(as a prefix string or :conc-name) or as entered from a user with
a readline equivalent, then the application should have a means
of converting the string as the reader would. I have found use
for the function (CASE-CONVERT-NAME <string>) which returns a
string which would be the name of a symbol if <string> were read
by the reader.
;;; This definition returns mostly the correct value,
;;; but has numerous unwanted side-effects,
;;; I.E. creates and interns a symbol, chokes on by colons, etc.
(defun CASE-CONVERT-NAME (string)
(symbol-name (read-from-string string)))
;;; this is much closer, with READTABLE-CASE-SENSITIVITY:READTABLE-KEYWORDS
(defun CASE-CONVERT-NAME (string)
(case (readtable-case-sensitivity *readtable*)
(:preserve string)
(:upcase (string-upcase string))
(:downcase (string-downcase string))
(:invert (string-invertcase string)) ;; uses char-invert-case?
))
;;; or this, with READTABLE-CASE-SENSITIVITY:READTABLE-FUNCTIONS
(defun CASE-CONVERT-NAME (string)
(map 'string (readtable-case-sensitivity *readtable*) string))
If we could have a function such as this in the, maybe folks
would use it: (intern (concatentate 'string
(case-convert-name "foo-")
(case-convert-name sym) )
pkg)
Instead of: (intern (concatentate 'string "FOO-" sym) pkg)
With this extra layer, writing protable code to case-sensitive lisp
is very much easier. The version i use even has an extra arguement
to control whether destructive (in-place) or copying conversion is done.
∂25-Mar-89 1209 CL-Cleanup-mailer Cleanup Meeting
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 25 Mar 89 12:09:47 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 565298; Sat 25-Mar-89 15:09:31 EST
Date: Sat, 25 Mar 89 15:09 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Cleanup Meeting
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890325150902.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Larry asked me to send mail clarifying that the Cleanup meeting will
be Tuesday morning at 8am at Contel, with full X3J13 to meet at 9am.
Probably all we'll have time to do at the early Cleanup meeting is
discuss strategy/priority for presentation--not discuss individual
issues.
∂29-Mar-89 1535 CL-Cleanup-mailer new version of LOAD-TRUENAME
Received: from ctc.contel.com (goofy.ctc.contel.com) by SAIL.Stanford.EDU with TCP; 29 Mar 89 15:35:10 PST
Received: from mickey.ctc.contel.com by ctc.contel.com (4.0/870914.1{Enger})
id AA11354; Wed, 29 Mar 89 18:35:27 EST
Received: by mickey.ctc.contel.com (4.0/SMI-4.0)
id AA01906; Wed, 29 Mar 89 18:36:33 EST
Date: Wed, 29 Mar 89 18:36:33 EST
From: mathis@mickey.ctc.contel.com (Bob Mathis)
Message-Id: <8903292336.AA01906@mickey.ctc.contel.com>
To: mathis@mickey.ctc.contel.com
Subject: new version of LOAD-TRUENAME
Cc: cl-cleanup@sail.stanford.edu
(composed by Moon w/editing by Masinter in Mathis office)
Issue: LOAD-TRUENAME
Forum: Cleanup
References: LOAD (p426), PROVIDE (p188), REQUIRE (p188),
Issue REQUIRE-PATHNAME-DEFAULTS
Category: ADDITION
Edit history: 13-Mar-89, Version 1 by Pitman
29-Mar-89, Version 2 by Moon (add -PATHNAME vars)
Problem Description:
It is difficult to construct sets of software modules which work
together as a unit and which port between different implementations.
REQUIRE and PROVIDE were intended to provide this level of support
but have `failed' to be portable in practice.
Typical user configurations involve a `system definition' file which
loads the modules of a `system' (collection of software modules).
Among the specific problems which arise are:
- File system types may vary. Different file syntax must be used for
each site.
- Even with the same Lisp implementation and host file system type,
the directory in which a software system resides may differ from
delivery site to delivery site.
- Multiple `copies' of the same system may reside in different
directories on the same machine.
Proposal (LOAD-TRUENAME:NEW-PATHNAME-VARIABLES):
Introduce new variables:
*LOAD-TRUENAME* [Variable]
This special variable is initially NIL, but is bound by LOAD to
hold the truename of the pathname of the file being loaded.
*COMPILE-FILE-TRUENAME* [Variable]
This special variable is initially NIL, but is bound by
COMPILE-FILE to hold the truename of the pathname of the file
being compiled.
*LOAD-PATHNAME* [Variable]
This special variable is initially NIL, but is bound by LOAD to
hold the pathname of the file being loaded.
*COMPILE-FILE-PATHNAME* [Variable]
This special variable is initially NIL, but is bound by
COMPILE-FILE to hold the pathname of the file being compiled.
Example:
------ File SETUP ------
(IN-PACKAGE 'MY-STUFF)
(DEFMACRO COMPILE-TRUENAME () `',*COMPILE-FILE-TRUENAME*)
(DEFVAR *SOURCE-FILE* (COMPILE-TRUENAME) "Just for debugging.")
(DEFVAR *LOADED-FILE* *LOAD-TRUENAME*)
(DEFUN LOAD-MY-SYSTEM ()
(DOLIST (MODULE-NAME '("FOO" "BAR" "BAZ"))
(LOAD (MERGE-PATHNAMES MODULE-NAME *LOAD-TRUENAME*))))
------------------------
(LOAD "SETUP")
(LOAD-MY-SYSTEM)
Rationale:
This satisfies the most common instances of the frequently reported
problem in the Problem Description.
Current Practice:
Wide variation.
In some implementations, calling LOAD binds or sets
*DEFAULT-PATHNAME-DEFAULTS* so that pathnames named in a file being
LOADed will default to being `nearby.'
Some implementations provide special variables that are similar or
identical to one or both of those proposed.
Some implementations have a way to represent the pathname for the
current working directory, and make the default pathname default
to that, so that loading without specifying a default again tends to
get `nearby' files.
None of these techniques is portable, unfortunately, because there
is no agreement.
Cost to Implementors:
Very small.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Continued difficulty for anyone trying to put a system of modules
in a form where they can be conveniently delivered using portable code.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
Negligible.
Discussion:
Touretzky raised the issue most recently on Common-Lisp. A number
of people immediately jumped on the bandwagon, indicating it was
important to them, too.
Pitman made three suggestions in response, of which the above is
the first. The others included:
2. Variables *LOAD-TRUENAMES* and *COMPILE-FILE-TRUENAMES* which hold
lists of the truenames of all files being loaded or compiled,
respectively, during the dynamic invocation of LOAD and COMPILE-FILE.
3. Variable *LOAD-OR-COMPILE-FILE-TRUENAMES* which holds a list like
((LOAD truename) (COMPILE-FILE truename) ...)
during the dynamic invocation of LOAD and COMPILE-FILE.
Touretzky responded:
``I like KMP's proposals. I like the second one best: have separate
variables for files being loaded and files being compiled, and use
them to maintain a stack so we can see the nesting of loads within
files.''
Pitman ultimately chose to present the first rather than the second
because it seemed simpler, easier to explain, and more likely to
pass at this late date.
!
Additional Comments:
"I favor LOAD-TRUENAME:NEW-PATHNAME-VARIABLES. I think this
proposal would be greatly improved by adding two more variables,
*LOAD-PATHNAME* and *COMPILE-FILE-PATHNAME*, whose values are
the pathname opened by LOAD or COMPILE-FILE, rather than the
truename. The need for these is more obvious if you think
about systems where the pathname cannot be easily reconstructed
from the truename. This includes file systems with symbolic
links and some pathname systems with logical pathnames."
"I favor this. I would even favor either of the other two ideas even at
this `late date'. The behavior of each of the proposals is simple, its
easy to see what it will and won't do, and it satisfies a real demand.
I should note that I have never wanted the incremented functionally
offered by the `stack' proposals, but I could still vote for them."
∂29-Mar-89 1550 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND, v.3
Received: from ctc.contel.com (goofy.ctc.contel.com) by SAIL.Stanford.EDU with TCP; 29 Mar 89 15:50:01 PST
Received: from mickey.ctc.contel.com by ctc.contel.com (4.0/870914.1{Enger})
id AA11389; Wed, 29 Mar 89 18:50:08 EST
Received: by mickey.ctc.contel.com (4.0/SMI-4.0)
id AA01917; Wed, 29 Mar 89 18:51:15 EST
Date: Wed, 29 Mar 89 18:51:15 EST
Message-Id: <8903292351.AA01917@mickey.ctc.contel.com>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: DESTRUCTURING-BIND, v.3
From: moon@symbolics.com
Issue: DESTRUCTURING-BIND
Forum: Cleanup
References: DEFMACRO (CLtL pp145-151),
The LOOP Facility (X3J13/89-004)
Category: ADDITION
Edit history: 24-Jan-89, Version 1 by Pitman
25-Jan-89, Version 2 by Pitman
29-Mar-89, Version 3, by Moon, amended based on poll
Problem Description:
Common Lisp programmers have frequently complained that the
destructuring facility used by DEFMACRO is not made available
for use in ordinary programming situations involving list data.
The presence of a destructuring facility in the recently adopted
LOOP facility will be likely to make the absence of a separable
destructuring facility all the more apparent.
Prior to the introduction of LET into Maclisp, many people wrote
their own LET macros. A popular expansion was in terms of a DO
which did not iterate. eg,
(LET ((A 3)) (+ A A)) ==> (DO ((A 3)) () (RETURN (+ A A)))
While this practice `worked,' it was not perspicuous and contributed
substantially to non-readability: not only were the macros hard to
understand, but the surface interface itself was not standardized
and varied in subtle ways. For example, some LET macros allowed GO
statements while others did not.
There is now considerable danger that a lot of people will write
DESTRUCTURING-BIND variants in terms of a LOOP expression that
immediately returns.
(DESTRUCTURING-BIND ((A B) C) (FOO) (LIST A B C))
==> (LOOP FOR ((A B) C) ON (FOO) DO (RETURN (LIST A B C)))
Since the destructuring offered by LOOP is different in subtle ways
from the destructuring offered by DESTRUCTURING-BIND in implementations
offering that primitive natively, gratuitous headaches could result.
Proposal (DESTRUCTURING-BIND:NEW-MACRO):
Provide a macro called DESTRUCTURING-BIND which behaves like the
destructuring bind in DEFMACRO. Specifically...
DESTRUCTURING-BIND lambda-list expression {decl}* {form}* [Macro]
Binds the variables specified in LAMBDA-LIST to the corresponding
values in the tree structure resulting from evaluating EXPRESSION,
then evaluates the FORMS in the body.
Anywhere in the LAMBDA-LIST where a parameter name may appear, and
where ordinary lambda-list syntax (as described in CLtL section 5.2.2)
does not otherwise allow a list, a lambda-list may appear in place of
the parameter name. When this is done, then the argument form that
would match the parameter is treated as a (possibly dotted) list, to
be used as an argument forms list for satisfying the parameters in
the embedded lambda-list.
If any of the lambda list keywords &OPTIONAL, &REST, &KEY,
&ALLOW-OTHER-KEYS and &AUX appears in the lambda list, it is treated
as with any other lambda-list.
If the lambda list keyword &BODY appears, it is treated as a synonym
for &REST.
The lambda list keyword &ENVIRONMENT is not allowed.
If the lambda list keyword &WHOLE appears, it must be followed by a
single variable that is bound to the entire expression at the current
level. &WHOLE and its following variable should appear first in the
list, before any other parameter or lambda-list keyword.
It is also permissible for any level of the LAMBDA-LIST to be dotted,
ending in a parameter name. This situation is treaed exactly as if
the aprameter name that ends the list had appeared preceded by &REST
in a proper list. For example, the notation (X Y . Z) is equivalent
to (X Y &REST Z).
If the result of evaluating the expression does not match the
destructuring pattern, an error should be signaled.
Test Case:
(DEFUN IOTA (N) (LOOP FOR I FROM 1 TO N COLLECT I)) ;helper
(DESTRUCTURING-BIND ((A &OPTIONAL (B 'BEE)) ONE TWO THREE)
`((ALPHA) ,@(IOTA 3))
(LIST A B THREE TWO ONE))
=> (ALPHA BEE 3 2 1)
Rationale:
The proposal directly addresses the stated problem, and is current practice
in numerous implementations. Our charter effectively dictates that where
feasible we should try to head off the widespread development of uselessly
different variants of commonplace tools.
The intent of the specification is to make DESTRUCTURING-BIND lambda-lists
compatible with inner-list elements of a macro lambda-list.
Current Practice:
Symbolics Genera, Envos Medley, TI Explorer, and Lucid CL all offer
DESTRUCTURING-BIND, though the details vary slightly.
The DESTRUCTURING-BIND offered by Symbolics Genera signals an error if
the pattern is not matched. The TI Explorer version does not.
Cost to Implementors:
Very small. In most cases, it's a matter of renaming and/or exporting an
already existing symbol. In a few cases, a very small amount of
`program interface' code would have to be written.
Cost to Users:
None. This is an upward compatible change.
Cost of Non-Adoption:
Loss of the Benefits and Aesthetics cited below.
Benefits:
Users will get a powerful feature they have asked for on many occassions.
In implementations which `autoload' code, it would be better for this
support to be separable so that people could do DESTRUCTURING-BIND
without demand loading all other LOOP support.
Aesthetics:
Defining this macro centrally for the Common Lisp community will reduce
subtle deviations, which will in turn have positive aesthetic impact.
Discussion:
JonL observes that although LOOP does destructuring, it can't directly
make use of the DESTRUCTURING-BIND interface suggested here.
Pitman and Gray think a facility of this sort is a good idea, though
obviously the details may still need a little fleshing out before the
proposal is ready for vote.
To date, the excuse for not satisfying this request has been a
religious war between factions who want to destructure lists by
writing
(DESTRUCTURING-BIND (var1 var2 var3) exp . body)
and those who want to destructure lists by writing
(DESTRUCTURING-BIND (LIST var1 var2 var3) exp . body)
The advantage of the former approach is that it is notationally
concise for the common case of destructuring a list. The disadvantage
is that it is not extensible to accomodate abstract kinds of
destructuring.
The advantage of the latter approach is that it allows interesting
extensions that accomodate data-hiding, such as:
(DEFMACRO MAKE-FOO (&REST ELEMENTS) `(LIST ,@ELEMENTS))
(DESTRUCTURING-BIND (MAKE-FOO var1 var2 var3) exp . body)
and later the ability to change the representation of a FOO without
updating the associated binding forms. The disadvantage is that it
is more verbose in the common case of destructuring a list, and still
even more verbose for nested lists.
Although destructuring has always existed in DEFMACRO, this has not
been adequate precedence for deciding the outcome of the religious war
because DEFMACRO only needs to destructure programs, and programs are
generally made up only of lists -- not arbitrary user-defined abstract
data types.
The lambda-list form of DESTRUCTURING-BIND in this version is
not completely compatible with the destructuring done by LOOP
in three areas: LOOP allows NIL elements of a list to be ignored,
LOOP does not allow &-keywords, and LOOP destructuring ignores
extra elements in the list being matched.
∂04-Apr-89 0804 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:04:40 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570859; Tue 4-Apr-89 11:04:34 EDT
Date: Tue, 4 Apr 89 11:04 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404110402.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say this was deferred to next meeting.
∂04-Apr-89 0805 CL-Cleanup-mailer Issue: BREAK-ON-WARNINGS-OBSOLETE
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:05:10 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570860; Tue 4-Apr-89 11:05:11 EDT
Date: Tue, 4 Apr 89 11:04 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: BREAK-ON-WARNINGS-OBSOLETE
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404110447.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say this passed unanimously with friendly amendment to
"remove" rather than "deprecate".
∂04-Apr-89 0805 CL-Cleanup-mailer Issue: CLOS-CONDITIONS
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:05:45 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570862; Tue 4-Apr-89 11:05:44 EDT
Date: Tue, 4 Apr 89 11:05 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CLOS-CONDITIONS
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404110518.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say this passed on a vote of N-0-3.
∂04-Apr-89 0808 CL-Cleanup-mailer Issue: CLOS-MACRO-COMPILATION
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:08:08 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570863; Tue 4-Apr-89 11:08:06 EDT
Date: Tue, 4 Apr 89 11:07 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CLOS-MACRO-COMPILATION
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404110742.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say that several amendments by Gregor were discussed but eventually
the issue was tabled until the next meeting. (A new version should be written
incorporating those amendments.)
Moon's notes add that on the issue of when forms are evaluated, Gregor's
amendment covered it for EQL parameter specializer names, but not for
DEFCONSTANT; perhaps DEFCONSTANT should be brought up as another cleanup.
∂04-Apr-89 0809 CL-Cleanup-mailer Issue: CLOSED-STREAM-OPERATIONS
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:09:00 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570864; Tue 4-Apr-89 11:09:01 EDT
Date: Tue, 4 Apr 89 11:08 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CLOSED-STREAM-OPERATIONS
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404110837.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say...
A motion to reconsider this issue passed N-2.
A motion to revoke version 7 and replace it with version 5 was made.
Walter van Roggen proposed we amend it to make all CLOSE return values
unspecified.
The motion to amend failed on a 3-4-N vote.
A recount was requested because people aren't permitted to abstain on
technical issues.
The motion still failed on a 6-8 vote.
The original motion (to replace v7 with v5) passed unamended 12-0.
∂04-Apr-89 0809 CL-Cleanup-mailer Issue: COERCE-INCOMPLETE
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:09:35 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570867; Tue 4-Apr-89 11:09:31 EDT
Date: Tue, 4 Apr 89 11:09 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COERCE-INCOMPLETE
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404110907.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say that someone made a motion for option DEPRECATE but it
died for lack of a second. This issue was marked withdrawn.
∂04-Apr-89 0816 CL-Cleanup-mailer Issue: COMMON-TYPE
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:10:06 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570871; Tue 4-Apr-89 11:10:01 EDT
Date: Tue, 4 Apr 89 11:09 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COMMON-TYPE
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404110930.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say this passed unanimously.
∂04-Apr-89 0817 CL-Cleanup-mailer Issue: COMPILE-FILE-SYMBOL-HANDLING
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:13:56 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570885; Tue 4-Apr-89 11:13:56 EDT
Date: Tue, 4 Apr 89 11:13 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COMPILE-FILE-SYMBOL-HANDLING
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404111332.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Moon's notes (mine were less complete) say there was disagreement about
which approach was worthwhile, so the committee will pursue option
REQUIRE-CONSISTENCY. They will delete ``must ensure'' since that is in
general impossible. People were asked to comment in mail (on the issue
of where SELECT-PACKAGE can go?).
This was deferred to next meeting.
∂04-Apr-89 0817 CL-Cleanup-mailer Issue: COMPILE-ENVIRONMENT-CONSISTENCY
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:11:16 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570878; Tue 4-Apr-89 11:11:16 EDT
Date: Tue, 4 Apr 89 11:10 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COMPILE-ENVIRONMENT-CONSISTENCY
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404111052.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say
``Gregor--Omit (g) 2nd sentence and say "structure or deftype" type specs''
Moon's notes agree and add
``For defclass, no info is compiled in, so superclass, metaclass, slots
can be different at load time. Change 3rd sentence not to apply to
DEFCLASS-defined types.''
This was tabled.
I also have a note to myself that I wondered if NOTINLINE and the FTYPE
declaration restrictions should interact.
∂04-Apr-89 0823 CL-Cleanup-mailer COMPILE-FILE-SYMBOL-HANDLING, COMPILE-ENVIRONMENT-CONSISTENCY
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:23:23 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570902; Tue 4-Apr-89 11:23:20 EDT
Date: Tue, 4 Apr 89 11:22 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: COMPILE-FILE-SYMBOL-HANDLING, COMPILE-ENVIRONMENT-CONSISTENCY
To: CL-Cleanup@SAIL.Stanford.EDU
References: <890404111332.7.KMP@BOBOLINK.SCRC.Symbolics.COM>,
<890404111052.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <890404112256.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
Oops--wrong list. Those were compiler issues. Please ignore them. Thanks.
∂04-Apr-89 0832 CL-Cleanup-mailer Issue: COMPLEX-RATIONAL-RESULT
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:32:12 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570916; Tue 4-Apr-89 11:32:14 EDT
Date: Tue, 4 Apr 89 11:31 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COMPLEX-RATIONAL-RESULT
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404113150.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say this passed n-0-2.
∂04-Apr-89 0833 CL-Cleanup-mailer Issue: CONDITION-RESTARTS
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:33:21 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570918; Tue 4-Apr-89 11:33:23 EDT
Date: Tue, 4 Apr 89 11:32 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CONDITION-RESTARTS
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404113259.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say this wasn't ready for a vote.
GZ wants us to flush COPY-CONDITION, which we're already planning to do.
IIM wants a :TEST keyword for restarts to allow them to selectively apply.
Loosemore wants not to forbid resignalling or any new version should relate
itself to item 3 of COMPILER-DIAGNOSTICS, which discusses resignalling.
Deferred to next meeting.
∂04-Apr-89 0834 CL-Cleanup-mailer Issue: COPY-SYMBOL-COPY-PLIST
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:34:19 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570919; Tue 4-Apr-89 11:34:14 EDT
Date: Tue, 4 Apr 89 11:33 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COPY-SYMBOL-COPY-PLIST
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404113350.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say this passed unanimously.
∂04-Apr-89 0834 CL-Cleanup-mailer Issue: COPY-SYMBOL-COPY-PRINT-NAME
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:34:43 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570920; Tue 4-Apr-89 11:34:43 EDT
Date: Tue, 4 Apr 89 11:34 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COPY-SYMBOL-COPY-PRINT-NAME
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404113419.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say this passed unanimously.
∂04-Apr-89 0835 CL-Cleanup-mailer Issue: DECLARE-FUNCTION-AMBIGUITY
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:35:21 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570921; Tue 4-Apr-89 11:35:24 EDT
Date: Tue, 4 Apr 89 11:35 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-FUNCTION-AMBIGUITY
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404113500.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
There was confusion about how this had worked out at the late meeting.
An incredibly weird vote on the question ``How many favor saying it passed
at the last meeting?'' passed N-0-M.
∂04-Apr-89 0842 CL-Cleanup-mailer Issue: DEFINE-OPTIMIZER
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:42:28 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570934; Tue 4-Apr-89 11:42:22 EDT
Date: Tue, 4 Apr 89 11:41 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFINE-OPTIMIZER
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404114158.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
After some fooling around with various amendments, this was brought to
a vote with the names DEFINE-COMPILER-MACRO (and I guess
COMPILER-MACROEXPAND and COMPILER-MACROEXPAND-1, though I realized later
that it was never made explicit) and failed 8-11-0.
I believe the issue may get re-opened. The reason is that I recently
realized that (a) users cannot write thing that ``should signal''
and (b) all they need to write things that ``should signal'' is
this functionality plus that provided in SYNTACTIC-ENVIRONMENT-ACCESS.
That's all I have to say for now. But don't be surprised if I have more
to say later.
∂04-Apr-89 0852 CL-Cleanup-mailer Issue: DEFMACRO-LAMBDA-LIST
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:52:40 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570949; Tue 4-Apr-89 11:52:39 EDT
Date: Tue, 4 Apr 89 11:52 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFMACRO-LAMBDA-LIST
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404115215.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
There were hardcopy amendments distributed. The hardcopy said:
Proposed amendments to DEFMACRO-LAMBDA-LIST KMP 3/30/89
(from MLY)
A. [Friendly] In 1b, change "may only appear at any level"
to "may appear at any level".
B. [Vote separately]
1. Prohibit/Permit (&whole W &environment E A B)
2. Prohibit/Permit (&environment E &whole W A B)
3. Prohibit/Permit (&whole W A B &environment E)
4. Prohibit/Permit (&whole W A &environment E B)
My notes say that we approved amendments A & B (``permit all four'')
and we added an amendment that said that &ENVIRONMENT would not be
duplicated in a DEFMACRO lambda-list.
The amended proposal was passed N-0-1.
∂04-Apr-89 0855 CL-Cleanup-mailer Issue: DEFMACRO-LAMBDA-LIST
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:54:55 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570953; Tue 4-Apr-89 11:54:56 EDT
Date: Tue, 4 Apr 89 11:54 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFMACRO-LAMBDA-LIST
To: CL-Cleanup@SAIL.Stanford.EDU
Supersedes: <890404115215.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <890404115432.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
There were hardcopy amendments distributed. The hardcopy said:
Proposed amendments to DEFMACRO-LAMBDA-LIST KMP 3/30/89
(from MLY)
A. [Friendly] In 1b, change "may only appear at any level"
to "may appear at any level".
B. [Vote separately]
1. Prohibit/Permit (&whole W &environment E A B) ``After &Whole''
2. Prohibit/Permit (&environment E &whole W A B) ``Before &Whole''
3. Prohibit/Permit (&whole W A B &environment E) ``Last''
4. Prohibit/Permit (&whole W A &environment E B) ``Middle''
My notes say that we approved amendments A & B (``permit all four'')
and we added an amendment that said that &ENVIRONMENT would not be
duplicated in a DEFMACRO lambda-list.
The amended proposal was passed N-0-1.
∂04-Apr-89 0855 CL-Cleanup-mailer Issue: DESCRIBE-UNDERSPECIFIED
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:55:17 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570954; Tue 4-Apr-89 11:55:17 EDT
Date: Tue, 4 Apr 89 11:54 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DESCRIBE-UNDERSPECIFIED
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404115453.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
An amendment was made (I think by Barrett) to make DESCRIBE deal with
its second argument in the same way as PRINT does (that is, permitting
arguments of NIL and T).
The amended proposal passed 15-0.
∂04-Apr-89 0857 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:57:16 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570958; Tue 4-Apr-89 11:57:09 EDT
Date: Tue, 4 Apr 89 11:56 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DESTRUCTURING-BIND
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404115645.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say that discussion on this was broken over two days with
quite a number of possible amendments discussed.
I came up with a written set of amendments for Thursday which were
discarded because Moon submitted a coherent revised proposal
(consistent with those amendments, and adding at least one other
feature not covered in those separate amendments) on Thursday.
The revised proposal was Moon's v3, already mailed.
The revised proposal was voted on, and passed 15-1.
∂04-Apr-89 1027 CL-Cleanup-mailer issue DYNAMIC-EXTENT-FUNCTION, version 1
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 4 Apr 89 10:27:27 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA29744; Tue, 4 Apr 89 11:27:25 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA19101; Tue, 4 Apr 89 11:27:23 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904041727.AA19101@defun.utah.edu>
Date: Tue, 4 Apr 89 11:27:21 MDT
Subject: issue DYNAMIC-EXTENT-FUNCTION, version 1
To: cl-cleanup@sail.stanford.edu
As promised, here's a first cut at this issue. I'm not particularly
attached to the name DYNAMIC-EXTENT-FUNCTION, but I'm still feeling
too burned out from arguing over what to rename DEFPROCLAIM to want to
waste a lot of time on thinking up alternate names for this one too. :-(
Forum: CLEANUP
Issue: DYNAMIC-EXTENT-FUNCTION
References: Scope and Extent
Issue DYNAMIC-EXTENT
Category: ADDITION
Edit history: 04-Apr-89, Version 1 by Loosemore
Problem Description:
Proposal DYNAMIC-EXTENT:NEW-DECLARATION, passed at the March 89
meeting, provides a mechanism for declaring that the values of
variables have only dynamic (rather than indefinite) extent. It
would be useful to have similar functionality to indicate that
functional bindings may have only dynamic extent. (For example,
this would permit compilers to stack-allocate closures.)
Proposal (DYNAMIC-EXTENT:NEW-DECLARATION):
Introduce a new declaration called DYNAMIC-EXTENT-FUNCTION. This is
identical to the DYNAMIC-EXTENT declaration, except that the
arguments name functions instead of variables.
Rationale:
This permits a programmer to offer advice to an implementation about
what functions may be stack-allocated for efficiency.
It may be difficult or impossible for a compiler to infer this
same information statically.
Current Practice:
JonL says that Lucid's compiler can stack-allocate closures, but they
have no mechanism for programmers to give the compiler permission to
do so.
HPCL-I has an UPWARD-CLOSURES declaration that pervasively affects
all closures created within the scope of the declaration.
Cost to Implementors:
No cost is forced since implementations are permitted to simply
ignore the DYNAMIC-EXTENT-FUNCTION declaration.
Cost to Users:
None. This change is upward compatible.
There may be some hidden costs to debugging using this declaration (or any
feature which permits the user to access dynamic extent objects without
the compiler proving that they are appropriate). If the user misdeclares
something and returns a pointer into the stack (or stores it in the heap),
an undefined situation may result and the integrity of the Lisp storage
mechanism may be compromised. Debugging these situations may be tricky,
but users who have asked for this feature have indicated a willingness
to deal with such costs. Nevertheless, the perils should be clearly
documented and casual users should not be encouraged to use this
declaration.
Cost of Non-Adoption:
Some portable code would be forced to run more slowly (due to
GC overhead), or to use non-portable language features.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
This declaration allows a fairly low level optimization to work
by asking the user to provide only very high level information.
The alternatives (sharpsign conditionals, some of which may
lead to more bit-picky abstractions) are far less aesthetic.
Discussion:
Loosemore supports DYNAMIC-EXTENT-FUNCTION:NEW-DECLARATION.
-------
∂04-Apr-89 1110 CL-Cleanup-mailer Issue: DYNAMIC-EXTENT
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 11:10:38 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571083; Tue 4-Apr-89 14:10:29 EDT
Date: Tue, 4 Apr 89 14:10 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DYNAMIC-EXTENT
To: CL-Cleanup@SAIL.Stanford.EDU
cc: sandra%defun@CS.Utah.EDU
Message-ID: <890404141003.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Sandra and Gabriel initially claimed to oppose this even in principle.
However, Steele and I drafted a revised proposal over lunch Thursday.
The text of the revised proposal was:
GLS and KMP 3/30/89
Amendment to DYNAMIC-EXTENT:NEW-DECLARATION
* Strike sentences 3 and 4 of paragraph 1.
* Move paragraphs 3 through n-1 to the examples.
* Strike last paragraph.
* Add this text after paragraph 1:
_Definition_: Object _x_ is an _otherwise_inaccessible_part_ (OIP)
of _y_ iff making _y_ inaccessible would make _x_ inaccessible.
(Note that every object is an OIP of itself.)
Suppose that construct _c_ contains a DYNAMIC-EXTENT declaration
for variable _v_ (which need not be bound by _c_). Consider the
values _w1_, ..., _wN_ taken on by _v_ during the course of some
execution of _c_. The declaration asserts that if object _x_ is
an OIP of _wI_ when _wI_ ever becomes the value of _v_, then
just after execution of _c_ terminates _x_ will be either
inaccessible or still an OIP of _v_.
The proposal was also amended in the meeting to say:
"If the assertion is ever violated, the conseqeuences are undefined."
The fully amended proposal passed 17-0.
It was generally agreed that we would also like to consider a proposal
on dynamic extent functions at the next meeting. (Sandra said she would
prepare one, and has already done so. See issue DYNAMIC-EXTENT-FUNCTION.)
∂04-Apr-89 1111 CL-Cleanup-mailer Issue: EQUALP-GENERIC
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 11:11:49 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571085; Tue 4-Apr-89 14:11:46 EDT
Date: Tue, 4 Apr 89 14:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EQUALP-GENERIC
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404141117.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say this issue was withdrawn by Barrett.
∂04-Apr-89 1114 CL-Cleanup-mailer Issue: ERROR-CHECKING-IN-NUMBERS-CHAPTER
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 11:14:07 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571087; Tue 4-Apr-89 14:13:58 EDT
Date: Tue, 4 Apr 89 14:13 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ERROR-CHECKING-IN-NUMBERS-CHAPTER
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404141334.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes show the following...
The major roadblocks were that GZ (and a few others) were hung up on the
presentation of ``should signal.''
GZ cited the example of (LOCALLY (DECLARE (OPTIMIZE (SAFETY 0))) #'+).
She wanted to know if the resulting function could fail to do error checking.
(RPG and KMP will pursue this.)
JonL really hated the presentation of the boole arguments using #.
RWK said we should definitely do this kind of stuff (error type identification)
now if possible, and not wait for the next standard.
Walter van Roggen was worried that some of this stuff might be controversial,
but I assured him that we would back off to a more vague error type
rather than dispute endlessly about controversial cases. He seemed happy with
that.
Haflich seemed to believe that this was especially important for numbers, so
he was happy to see this chapter done.
Masinter said that with his implementor's hat on, he thought this was a pain,
but that with his user's hat on, he liked it. He was letting his user side
dominate and being very supportive.
There was consensus that we should discuss this (and similar proposals) at
the next meeting.
∂04-Apr-89 1115 CL-Cleanup-mailer Issue: ERROR-NOT-HANDLED
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 11:15:19 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571089; Tue 4-Apr-89 14:15:16 EDT
Date: Tue, 4 Apr 89 14:14 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ERROR-NOT-HANDLED
To: CL-Cleanup@SAIL.Stanford.EDU
cc: chapman%aitg.dec@decwrl.dec.com
Message-ID: <890404141451.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say this issue was withdrawn in favor of providing Kathy with
editorial advice to `minimize implicit requirements on debuggers' in the
presentation of the debugger in the standard.
Kathy- if the implication of that is not clear, let me know privately
and I'll help you get that in order.
∂04-Apr-89 1117 CL-Cleanup-mailer Issue: FUNCTION-COERCE-TIME
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 11:16:47 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571092; Tue 4-Apr-89 14:16:48 EDT
Date: Tue, 4 Apr 89 14:16 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-COERCE-TIME
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404141624.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes show this as withdrawn.
The editors were instructed to be explicitly vague 16-1.
∂04-Apr-89 1125 CL-Cleanup-mailer Issue: EXIT-EXTENT
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 11:16:19 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571091; Tue 4-Apr-89 14:16:18 EDT
Date: Tue, 4 Apr 89 14:15 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXIT-EXTENT
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404141553.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
This was characterized by someone as ``the unstoppable throw meeting the
immovable catch.''
I offered a "one time only" offer to support option MINIMAL if we could
just get this off the table this week and not keep deferring it.
Moon offered some amendments the effect of which were to allow you to throw again
to the same tag as you were already throwing to; specifically:
In the first paragraph of the MINIMAL proposal, delete "or is itself the
target exit" and change "events (c) and (d) at" to "event (c) occurs at".
After the first paragraph add a new paragraph "The event (d) occurs at the
end of the transfer of control."
The proposal was amended, and the amended option MINIMAL passed 11-5.
∂04-Apr-89 1127 CL-Cleanup-mailer Re: Issue: DYNAMIC-EXTENT
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 11:26:13 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 571107; 4 Apr 89 14:21:42 EDT
Date: Tue, 4 Apr 89 14:21 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: DYNAMIC-EXTENT
To: sandra%defun@cs.utah.edu
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8904041817.AA19138@defun.utah.edu>
Message-ID: <890404142113.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Tue, 4 Apr 89 12:17:17 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
> Sandra and Gabriel initially claimed to oppose this even in principle.
Gack -- I've been misquoted! The principle is fine with me and the
revision fixed the thing that bugged me the most (making the
declaration apply to *any* value assigned to the variable instead of
just its initial value) about the original proposal.
Ok, I stand corrected -- and I'm glad to see you're happy with what
we decided.
The whole reason I'm distributing this stuff is to make sure my view of
what happened aligns with other people's. I guess if it's catching
discrepancies, that's a sign that the process is worthwhile. :-}
∂04-Apr-89 1127 CL-Cleanup-mailer Issue: FUNCTION-NAME
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 11:17:21 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571095; Tue 4-Apr-89 14:17:15 EDT
Date: Tue, 4 Apr 89 14:16 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-NAME
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404141651.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes show the following...
We voted in order SMALL, MEDIUM, then LARGE.
Each time, the attempt was to replace the previous.
Option SMALL passed 15-2.
Option MEDIUM passed 9-6, superseding SMALL.
Option LARGE passed 13-2-3, superseding MEDIUM.
The minutes probably just reflect LARGE having been passed.
Moon then moved that we reconsider parts of LARGE -- parts 4,7,8,9.
We agreed to reconsider.
Sandra moved to retract 4,7,8,9.
RPG amended the proposal to affect GENERIC-FLET and GENERIC-LABELS, too,
for consistency.
RPG's amendment to Sandra's motion passed.
We voted on each part of Sandra's motion separately:
Strike 4? No. (Failed 3-15)
Strike 7? Yes. (Passed 16-1)
Strike 8? Yes. (Passed 16-0)
Strike 9? Yes (Passed 17-0-1)
There was some question about 9's relation to SYNTACTIC-ENVIRONMENT-ACCESS.
The net effect is that option LARGE passed with amendments to strike 7,8,9.
∂04-Apr-89 1133 CL-Cleanup-mailer Re: Issue: DYNAMIC-EXTENT
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 4 Apr 89 11:17:25 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA02524; Tue, 4 Apr 89 12:17:20 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA19138; Tue, 4 Apr 89 12:17:18 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904041817.AA19138@defun.utah.edu>
Date: Tue, 4 Apr 89 12:17:17 MDT
Subject: Re: Issue: DYNAMIC-EXTENT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@SAIL.Stanford.EDU, sandra%defun@cs.utah.edu
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 4 Apr 89 14:10 EDT
> Sandra and Gabriel initially claimed to oppose this even in principle.
Gack -- I've been misquoted! The principle is fine with me and the
revision fixed the thing that bugged me the most (making the
declaration apply to *any* value assigned to the variable instead of
just its initial value) about the original proposal.
-Sandra
-------
∂04-Apr-89 1133 CL-Cleanup-mailer Issue: GENSYM-NAME-STICKINESS
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 11:17:42 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571096; Tue 4-Apr-89 14:17:43 EDT
Date: Tue, 4 Apr 89 14:17 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: GENSYM-NAME-STICKINESS
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404141718.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Option LIKE-TEFLON passed 17-0.
There was general agreement that the issue name was an example of good marketing
and helped the proposal slide right through.
∂04-Apr-89 1147 CL-Cleanup-mailer Issue: HASH-TABLE-ACCESS
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 11:47:01 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571158; Tue 4-Apr-89 14:46:59 EDT
Date: Tue, 4 Apr 89 14:46 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-ACCESS
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404144633.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say this passed 17-0 with hand-written amendments by me
(and agreement that the `obvious' write-o's would be corrected).
The [corrected] hand-written text says:
Amendment to HASH-TABLE-ACCESS KMP 3/30/89
Add: Define that the results of HASH-TABLE-REHASH-SIZE,
HASH-TABLE-REHASH-THRESHOLD, and HASH-TABLE-SIZE
are suitable for use in a call to MAKE-HASH-TABLE
in order to produce a hash table with state
corresponding to the current state of the hash table.
Clarify that the result of HASH-TABLE-TEST is always a
symbol naming a function rather than the function itself if
the test is one of those defined by this standard.
(Implementations which provide additional tests for hash
tables may determine how this function relates to such
extended tests.)
∂04-Apr-89 1148 CL-Cleanup-mailer Issue: HASH-TABLE-SIZE
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 11:48:15 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 571161; 4 Apr 89 14:47:57 EDT
Date: Tue, 4 Apr 89 14:47 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-SIZE
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404144729.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
It was suprising to me how much controversy there was on this.
Moon thinks the basic disagreement is that some people (JonL) think that
the hash nature of tables should be explicitly exposed and other people
(Moon) think it should be hidden; consider a fixnum value for
:rehash-threshold, which interacts with the value of :size, according
to JonL.
This issue was deferred to the next meeting on a 13-2 vote.
∂04-Apr-89 1149 CL-Cleanup-mailer Issue: IN-PACKAGE-FUNCTIONALITY
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 11:48:54 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571162; Tue 4-Apr-89 14:48:52 EDT
Date: Tue, 4 Apr 89 14:48 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: IN-PACKAGE-FUNCTIONALITY
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404144827.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
From my notes...
On Tuesday, we took a straw poll.
0 opposed both proposals.
15 liked NEW-MACRO.
7 liked SELECT-ONLY.
``Keeping IN-PACKAGE makes no difference to compatibility.'' --Moon
Pitman moved to amend this to say "deprecate" instead of remove.
The motion to amend failed 3-N.
The NEW-MACRO proposal passed unamended 12-4.
On Thursday, Aaron Larson and JonL asked that the issue be reconsidered.
The motion to reconsider passed N-1.
There was a motion to rename the SELECT-PACKAGE which we'd voted in to
IN-PACKAGE -- so that the compatible syntax (IN-PACKAGE "FOO") would work
in CLtL and ANSI CL.
Steele requested verbal clarification that we were not trying to solve
the ``dusty file'' problem but rather to make it possible to write new code
that worked in old and new situations -- it was agreed that this was a
correct characterization of the proposal.
JonL's amendment passed 13-1.
Then the amended proposal was voted in 14-0.
The net effect is that NEW-MACRO passed with the name of SELECT-PACKAGE
changed to IN-PACKAGE.
∂04-Apr-89 1153 CL-Cleanup-mailer Issue: IN-SYNTAX
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 11:53:13 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571174; Tue 4-Apr-89 14:53:10 EDT
Date: Tue, 4 Apr 89 14:52 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: IN-SYNTAX
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404145245.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Version 2, which makes LOAD and *COMPILE-FILE* bind *READTABLE* (and
which does -not- introduce the IN-SYNTAX macro mentioned in version 1)
passed 12-0-3. This version was distributed by KMP in handwritten form.
The full text of the hand-written proposal was:
Issue IN-SYNTAX (Version 2) KMP 3/30/89
Proposal (IN-SYNTAX:MINIMAL):
Define that COMPILE-FILE and LOAD bind *READTABLE* to its
current value.
Rationale:
This allows portable programs to do
(IN-PACKAGE "FOO")
(EVAL-WHEN (EVAL LOAD COMPILE)
(SETQ *READTABLE* FOO:MY-READTABLE))
at the top of a file without globally side-effecting the
environment.
Currently, there is no portable way to change the syntax only for
the duration of a file, which in turn makes customized syntax
difficult to use safely.
∂04-Apr-89 1156 CL-Cleanup-mailer Issue: LISP-PACKAGE-NAME
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 11:56:22 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571175; Tue 4-Apr-89 14:56:13 EDT
Date: Tue, 4 Apr 89 14:55 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LISP-PACKAGE-NAME
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404145549.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say...
Steele suggested amending this to rename package USER to COMMON-LISP-USER.
The amendment was accepted as a friendly amendment.
The proposal was passed 12-4.
Barry Margolin wanted the package COMMON-LISP-USER to have nickname CL-USER.
Amendment accepted (after the original proposal was approved) 11-0-n.
The net effect is that this passed with amendment to rename package USER to
COMMON-LISP-USER with nickname CL-USER.
∂04-Apr-89 1200 CL-Cleanup-mailer Issue: LISP-SYMBOL-REDEFINITION
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 11:59:22 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571187; Tue 4-Apr-89 14:59:17 EDT
Date: Tue, 4 Apr 89 14:58 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LISP-SYMBOL-REDEFINITION
To: CL-Cleanup@SAIL.Stanford.EDU
cc: sandra%defun@SAIL.Stanford.EDU
Message-ID: <890404145850.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
I need some help here. My notes say:
GZ wanted an amendment to strike item 8 from this list.
Sandra had some concern about the penultimate paragraph where she wanted a
prohibition on the ability to trace local functions (in implementations that
permit that). Moon thinks the proposal was amended to explicitly allow
tracing of such local function bindings.
>> Sandra: Please resolve this!
We went round in circles about item 8. A straw poll to send this back for
more work failed 6-10, so we kept on.
A motion was made to terminate discussion. This passed by 2/3 vote.
Moon's notes say item 8 may need further refinement, as for instance by GLS's
amendment. The goal is to separate properties into the ones the user can
bash and the ones the user cannot bash. [Anyway, we should expect that item 8
may come up in some form at the next meeting.]
Ultimately, I have written in my notes that we voted on
``proposal replaced by RPG, item 8 struck, w/ Sandra's prohibition
to trace local functions''
and that it passed 14-3.
>> This might not be accurate depending on how the discrepancy above is resolved.
∂04-Apr-89 1206 CL-Cleanup-mailer Issue: LOAD-OBJECTS (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:06:42 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571193; Tue 4-Apr-89 15:06:37 EDT
Date: Tue, 4 Apr 89 15:06 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-OBJECTS (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404150611.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
Moon proposed friendly amendment to use the name MAKE-LOAD-FORM-SAVING-SLOTS.
The amended proposal passed 18-0.
I had to produce a revised writeup for my own purposes anyway, so it's
attached below.
-----
Issue: LOAD-OBJECTS
References: none
Related issues: LOAD-TIME-EVAL,
CONSTANT-COMPILABLE-TYPES,
CONSTANT-CIRCULAR-COMPILATION
Category: ADDITION
Forum: Cleanup
Edit history: Version 1, 2-Jan-89, by Moon (for discussion)
Version 2, 13-Jan-89, by Moon (draft updated from discussion)
Version 3, 9-Mar-89, by Moon (changes suggested by discussion)
Version 4, 4-Apr-89, by Pitman (changes per X3J13 Mar 89;
MAKE-LOAD-FORM-USING-SLOTS => MAKE-LOAD-FORM-SAVING-SLOTS)
Status: Accepted by an 18-0 vote, March 1989.
Problem description:
Common Lisp doesn't provide any way to use an object of a user-defined
type (defined with DEFCLASS or DEFSTRUCT) as a constant in a program
compiled with COMPILE-FILE. The problem is that LOAD has to be able
to "reconstruct" an equivalent object when the compiled-code file is
loaded, but the programmer has no way to tell LOAD how to do that.
Proposal (LOAD-OBJECTS:MAKE-LOAD-FORM):
Define a new generic function named MAKE-LOAD-FORM, which takes one
argument and returns two values. The argument is an object that is
referenced as a constant or as a self-evaluating form in a file being
compiled by COMPILE-FILE. The objective is to enable LOAD to
construct an equivalent object.
The first value, called the "creation form," is a form that, when
evaluated at load time, should return an object that is equivalent to
the argument. The exact meaning of "equivalent" depends on the type
of object and is up to the programmer who defines a method for
MAKE-LOAD-FORM. This is the same type of equivalence discussed
in issue CONSTANT-COMPILABLE-TYPES.
The second value, called the "initialization form," is a form that,
when evaluated at load time, should perform further initialization of
the object. The value returned by the initialization form is ignored.
If the MAKE-LOAD-FORM method returns only one value, the
initialization form is NIL, which has no effect. If the object used
as the argument to MAKE-LOAD-FORM appears as a constant in the
initialization form, at load time it will be replaced by the
equivalent object constructed by the creation form; this is how the
further initialization gains access to the object.
Both the creation form and the initialization form can contain
references to objects of user-defined types (defined precisely below).
However, there must not be any circular dependencies in creation forms.
An example of a circular dependency is when the creation form for the
object X contains a reference to the object Y, and the creation form
for the object Y contains a reference to the object X. A simpler
example would be when the creation form for the object X contains
a reference to X itself. Initialization forms are not subject to
any restriction against circular dependencies, which is the entire
reason that initialization forms exist. See the example of circular
data structures below.
The creation form for an object is always evaluated before the
initialization form for that object. When either the creation form or
the initialization form references other objects of user-defined types
that have not been referenced earlier in the COMPILE-FILE, the
compiler collects all of the creation and initialization forms. Each
initialization form is evaluated as soon as possible after its
creation form, as determined by data flow. If the initialization form
for an object does not reference any other objects of user-defined
types that have not been referenced earlier in the COMPILE-FILE, the
initialization form is evaluated immediately after the creation form.
If a creation or initialization form F references other objects of
user-defined types that have not been referenced earlier in the
COMPILE-FILE, the creation forms for those other objects are evaluated
before F, and the initialization forms for those other objects are
also evaluated before F whenever they do not depend on the object
created or initialized by F. Where the above rules do not uniquely
determine an order of evaluation, which of the possible orders of
evaluation is chosen is unspecified.
While these creation and initialization forms are being evaluated, the
objects are possibly in an uninitialized state, analogous to the state
of an object between the time it has been created by ALLOCATE-INSTANCE
and it has been processed fully by INITIALIZE-INSTANCE. Programmers
writing methods for MAKE-LOAD-FORM must take care in manipulating
objects not to depend on slots that have not yet been initialized.
It is unspecified whether LOAD calls EVAL on the forms or does some
other operation that has an equivalent effect. For example, the
forms might be translated into different but equivalent forms and
then evaluated, they might be compiled and the resulting functions
called by LOAD, or they might be interpreted by a special-purpose
interpreter different from EVAL. All that is required is that the
effect be equivalent to evaluating the forms.
COMPILE-FILE calls MAKE-LOAD-FORM on any object that is referenced as
a constant or as a self-evaluating form, if the object's metaclass is
STANDARD-CLASS, STRUCTURE-CLASS, any user-defined metaclass (not a
subclass of BUILT-IN-CLASS), or any of a possibly-empty
implementation-defined list of other metaclasses. COMPILE-FILE will
only call MAKE-LOAD-FORM once for any given object (compared with EQ)
within a single file.
It is valid for user programs to call MAKE-LOAD-FORM in other
circumstances, providing the argument's metaclass is not BUILT-IN-CLASS
or a subclass of BUILT-IN-CLASS.
Define a new function named MAKE-LOAD-FORM-SAVING-SLOTS, which takes
one required argument and one optional argument and returns two
values. This can be useful in user-written MAKE-LOAD-FORM methods.
The first argument is the object. The optional second argument is a
list of the names of the slots to preserve; it defaults to all of the
local slots. MAKE-LOAD-FORM-SAVING-SLOTS returns forms that construct
an equivalent object using MAKE-INSTANCE and SETF of SLOT-VALUE for
slots with values, or SLOT-MAKUNBOUND for slots without values, or
using other functions of equivalent effect.
MAKE-LOAD-FORM-SAVING-SLOTS returns two values, thus it can deal with
circular structures. MAKE-LOAD-FORM-SAVING-SLOTS works for any object
of metaclass STANDARD-CLASS or STRUCTURE-CLASS. Whether the result is
useful in an application depends on whether the object's type and slot
contents fully capture the application's idea of the object's state.
MAKE-LOAD-FORM of an object of metaclass STANDARD-CLASS or
STRUCTURE-CLASS for which no user-defined method is applicable signals
an error. It is valid to implement this either by defining default
methods on STANDARD-OBJECT and STRUCTURE-OBJECT that signal an error
or by having no applicable method for those classes.
Examples:
;; Example 1
(defclass my-class ()
((a :initarg :a :reader my-a)
(b :initarg :b :reader my-b)
(c :accessor my-c)))
(defmethod shared-initialize ((self my-class) ignore &rest ignore)
(unless (slot-boundp self 'c)
(setf (my-c self) (some-computation (my-a self) (my-b self)))))
(defmethod make-load-form ((self my-class))
`(make-instance ',(class-name (class-of self))
:a ',(my-a self) :b ',(my-b self)))
In this example, an equivalent instance of my-class is reconstructed
by using the values of two of its slots. The value of the third slot
is derived from those two values.
Another way to write the last form in the above example would have been
(defmethod make-load-form ((self my-class))
(make-load-form-saving-slots self '(a b)))
;; Example 2
(defclass my-frob ()
((name :initarg :name :reader my-name)))
(defmethod make-load-form ((self my-frob))
`(find-my-frob ',(my-name self) :if-does-not-exist :create))
In this example, instances of my-frob are "interned" in some way.
An equivalent instance is reconstructed by using the value of the
name slot as a key for searching existing objects. In this case
the programmer has chosen to create a new object if no existing
object is found; alternatively she could have chosen to signal an
error in that case.
;; Example 3
(defclass tree-with-parent () ((parent :accessor tree-parent)
(children :initarg :children)))
(defmethod make-load-form ((x tree-with-parent))
(values
;; creation form
`(make-instance ',(class-of x) :children ',(slot-value x 'children))
;; initialization form
`(setf (tree-parent ',x) ',(slot-value x 'parent))))
In this example, the data structure to be dumped is circular, because
each parent has a list of its children and each child has a reference
back to its parent. Suppose make-load-form is called on one object in
such a structure. The creation form creates an equivalent object and
fills in the children slot, which forces creation of equivalent
objects for all of its children, grandchildren, etc. At this point
none of the parent slots have been filled in. The initialization form
fills in the parent slot, which forces creation of an equivalent
object for the parent if it was not already created. Thus the entire
tree is recreated at load time. At compile time, MAKE-LOAD-FORM is
called once for each object in the true. All of the creation forms
are evaluated, in unspecified order, and then all of the
initialization forms are evaluated, also in unspecified order.
;; Example 4
(defstruct my-struct a b c)
(defmethod make-load-form ((s my-struct))
(make-load-form-saving-slots s))
In this example, the data structure to be dumped has no special
properties and an equivalent structure can be reconstructed
simply by reconstructing the slots' contents.
Rationale:
Only the programmer who designed a class can know the correct
way to reconstruct objects of that class at load time, therefore
the reconstruction should be controlled by a generic function.
Using EVAL as the interface for telling LOAD what to do provides
full generality.
MAKE-LOAD-FORM returns two values so that circular structures can
be handled. If CONSTANT-CIRCULAR-COMPILATION is rejected,
MAKE-LOAD-FORM will only return one value, although implementations
that make an extension to support circular constants will probably
also make the extension to accept two values from MAKE-LOAD-FORM.
The default for class objects and structures is to signal an error,
rather than picking some particular object reconstruction technique,
because no reconstruction technique is appropriate for all objects.
It only takes two lines of code, as in example 4, to instruct the
compiler to use the technique that most often has been suggested
as the default.
MAKE-LOAD-FORM has a natural resemblance to PRINT-OBJECT, as a hook
for the programmer to control the system's actions.
The order of evaluation rules for creation and initialization forms
eliminate the possibility of partially initialized objects in the
absence of circular structures, and reduce it to the minimum possible
in the presence of circular structures. This allows nodes in
non-circular structures to be built out of fully initialized subparts.
Current practice:
Symbolics Flavors has something like this, but under a different name.
The name Symbolics uses is not suitable for standardization.
JonL reports that Lucid is getting more and more requests for this.
Cost to Implementors:
This seems like only a few one-line changes in the compiled-code
file writer and reader. MAKE-LOAD-FORM-SAVING-SLOTS is a couple
dozen lines of code, assuming the presence of the CLOS metaobject
protocol or an implementation-dependent equivalent.
Cost to Users:
None.
Cost of non-adoption:
Serious impairment of the ability to use extended-type objects. Each
implementation will probably make up its own version of this as an
extension.
Performance impact:
None.
Benefits:
See Cost of non-adoption.
Esthetics:
No significant positive or negative impact.
Discussion:
It would be possible to define an additional level of protocol that
allows multiple classes to contribute to the reconstruction of an
object, combining initialization arguments contributed by each class.
Since a user can easily define that in terms of MAKE-LOAD-FORM without
modifying the Lisp system, it is not being proposed now.
Any type that has a read syntax is likely to appear as a quoted
constant or inside a quoted constant. Pathnames are one example, user
programs often define others. Also many implementations provide a way
to create a compiled-code file full of data (rather than compiled Lisp
programs), and such data probably include extended-type objects.
Moon supports this. David Gray and John Rose made major contributions
to the discussion that produced this improved version 2 proposal.
∂04-Apr-89 1217 CL-Cleanup-mailer Issue: LOAD-TRUENAME
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:17:37 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571207; Tue 4-Apr-89 15:17:27 EDT
Date: Tue, 4 Apr 89 15:17 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TRUENAME
To: CL-Cleanup@SAIL.Stanford.EDU
cc: Loeffler@MCC.Com
Message-ID: <890404151703.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say that Moon wanted some other variables. I wrote this up as
an amendment, but neither the amendment nor the proposal was ever voted on.
Moon mailed out a version 2 but then withdrew it in favor of my amendment.
The text of my amendment was:
Proposed amendment to LOAD-TRUENAME KMP 3/30/89
Also introduce new variables:
*LOAD-PATHNAME*
This special variable is initially NIL but is bound by LOAD
to hold a pathname which represents the filename given as the
first argument to LOAD. That is, (PATHNAME arg1).
*COMPILE-FILE-PATHNAME*
This special variable is initially NIL but is bound by COMPILE-FILE
to hold a pathname which represents the filename given as the
first argument to COMPILE-FILE. That is, (PATHNAME arg1).
Rationale:
The truename may be useful to tell the real file being loaded,
but sometimes information about the link names or logical devices
traversed is important, too.
Note that these new variables alone are not adequate since
TRUENAME on these pathnames might not yield the value of the
-TRUENAME* variables if the file has been deleted or protected
since the open occurred (in some implementations).
The problem is whether the values of the -pathname variables is the
original argument or the merged, defaulted value. Moon thinks it
should be the latter. I think there are arguments for either
one, but also think that this sub-issue is "in the noise" and
should not hold up progress. Loeffler volunteered to work on this.
By a 14-1 vote, we deferred this to the next meeting.
∂04-Apr-89 1219 CL-Cleanup-mailer Issue: LOCALLY-TOP-LEVEL
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:19:22 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571209; Tue 4-Apr-89 15:19:16 EDT
Date: Tue, 4 Apr 89 15:18 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOCALLY-TOP-LEVEL
To: CL-Cleanup@SAIL.Stanford.EDU
cc: Dick@Wheaties.AI.MIT.EDU
Message-ID: <890404151849.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
[Waters added for sake of amusing story at end.]
My notes say this passed unanimously.
I also noted that this took 15 seconds to vote in. In fact, we did it
while in the middle of PRETTY-PRINT-INTERFACE sort of at ``interrupt level''
in a way that confused Mary's taking of the minutes and we -almost- got
the pretty printer marked as voted in because she didn't realize we'd
shifted topics.
∂04-Apr-89 1219 CL-Cleanup-mailer Issue: LOOP-AND-DISCREPANCY
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:19:40 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571210; Tue 4-Apr-89 15:19:35 EDT
Date: Tue, 4 Apr 89 15:19 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOOP-AND-DISCREPANCY
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404151910.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say this passed 14-0.
∂04-Apr-89 1221 CL-Cleanup-mailer Issue: MACRO-ENVIRONMENT-EXTENT
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:21:23 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571211; Tue 4-Apr-89 15:21:17 EDT
Date: Tue, 4 Apr 89 15:20 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: MACRO-ENVIRONMENT-EXTENT
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152045.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say...
Gregor says "the cartel" thinks CLOS is unaffected by this proposal.
In a straw poll, we checked which option people favor.
11 DYNAMIC
7 `not DYNAMIC'
It later became clear that some people thought DYNAMIC-WITH-COPIER
was in the `not DYNAMIC' set.
In spite of the confusion, option DYNAMIC passed 15-1.
A motion to replace option DYNAMIC with option DYNAMIC-WITH-COPIER
failed 1-12.
∂04-Apr-89 1221 CL-Cleanup-mailer Issue: MAKE-STRING-FILL-POINTER
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:21:38 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571212; Tue 4-Apr-89 15:21:32 EDT
Date: Tue, 4 Apr 89 15:21 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: MAKE-STRING-FILL-POINTER
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152107.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Someone (GZ?) objected that this would change the result type from MAKE-STRING
from being a simple-string, and would break type inferencing code.
It was agreed that this should be withdrawn.
∂04-Apr-89 1222 CL-Cleanup-mailer Issue: PACKAGE-FUNCTION-CONSISTENCY
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:22:38 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571216; Tue 4-Apr-89 15:22:10 EDT
Date: Tue, 4 Apr 89 15:21 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-FUNCTION-CONSISTENCY
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152140.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
This was on the agenda but not discussed.
Since it is just a clarification, I assume it could still come
up at the next meeting.
∂04-Apr-89 1226 CL-Cleanup-mailer Issue: PATHNAME-LOGICAL
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:25:09 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571228; Tue 4-Apr-89 15:25:06 EDT
Date: Tue, 4 Apr 89 15:24 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-LOGICAL
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152441.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
This was deferred to the next meeting.
Moon says that Masinter "tried manfully" to encourage him to write up a
proposal, but I doubt anyone really expects it to happen.
∂04-Apr-89 1227 CL-Cleanup-mailer Issue: PATHNAME-PRINT-READ
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:27:19 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571237; Tue 4-Apr-89 15:27:19 EDT
Date: Tue, 4 Apr 89 15:26 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-PRINT-READ
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152654.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
This was deferred from Tuesday to Thursday but then didn't come
around for discussion due to lack of time.
I guess I think it's possible that this could still come up at
the next meeting since it can at least be argued to be a clarification.
Others might disagree though.
∂04-Apr-89 1227 CL-Cleanup-mailer Issue: PATHNAME-CANONICAL-TYPE
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:23:18 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571220; Tue 4-Apr-89 15:23:07 EDT
Date: Tue, 4 Apr 89 15:22 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-CANONICAL-TYPE
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152241.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
This was identified as `medium' importance in the pathname world
and deferred to the next meeting.
∂04-Apr-89 1231 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:28:56 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571239; Tue 4-Apr-89 15:28:55 EDT
Date: Tue, 4 Apr 89 15:28 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152831.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
This was identified as `important' and deferred to the
next meeting.
∂04-Apr-89 1232 CL-Cleanup-mailer Issue: PEEK-CHAR-READ-CHAR-ECHO
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:31:23 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571244; Tue 4-Apr-89 15:31:19 EDT
Date: Tue, 4 Apr 89 15:30 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PEEK-CHAR-READ-CHAR-ECHO
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404153055.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Kim Barrett mentioned again that he wants to reopen this, but nothing
was done at this meeting.
∂04-Apr-89 1233 CL-Cleanup-mailer Issue: PRETTY-PRINT-INTERFACE
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:31:42 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571245; Tue 4-Apr-89 15:31:40 EDT
Date: Tue, 4 Apr 89 15:31 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PRETTY-PRINT-INTERFACE
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404153114.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say this was deferred to the next meeting by a vote of N-2.
∂04-Apr-89 1235 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-CASE
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:24:06 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571225; Tue 4-Apr-89 15:23:56 EDT
Date: Tue, 4 Apr 89 15:23 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-COMPONENT-CASE
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152331.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
This was identified as `important' and deferred to
the next meeting (with explicit exception to cut-off
date on 18-0 vote).
∂04-Apr-89 1238 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:36:44 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571257; Tue 4-Apr-89 15:36:39 EDT
Date: Tue, 4 Apr 89 15:36 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL
To: CL-Cleanup@SAIL.Stanford.EDU
cc: JAR@AI.AI.MIT.EDU
Message-ID: <890404153614.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say...
KMP made a friendly amendment to clarify the status of undeclared
free variables (as undefined). The text of the amendment was:
-----
Proposed amendment to PROCLAIM-LEXICAL KMP 3/30/89
Add: Referencing a free variable that is neither proclaimed
nor declared LEXICAL nor SPECIAL has undefined
consequences.
Rationale:
This enables existing implementations to persist in permitting,
for example,
(SETQ X 3)
without defining X as lexical or special, yet allows those
implementations that want to warn about
(DEFUN F (X) (+ X Y))
when Y is undeclared/proclaimed to legitimately do so.
-----
GZ wanted an amendment that would make it an error to use the LEXICAL
declaration when there was not a lexically visible binding to which
it might refer. Her amendment failed 5-12.
The proposal (with friendly amendment by KMP but without GZ's
amendment) finally failed 6-11.
∂04-Apr-89 1238 CL-Cleanup-mailer Issue: READ-CASE-SENSITIVITY
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:38:11 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571263; Tue 4-Apr-89 15:37:46 EDT
Date: Tue, 4 Apr 89 15:37 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: READ-CASE-SENSITIVITY
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404153716.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
This was deferred to the next meeting by a 13-3 vote.
The drafters were requested to present only a single alternative.
∂04-Apr-89 1240 CL-Cleanup-mailer Issue: READ-DELIMITED-LIST-EOF
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:38:46 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571265; Tue 4-Apr-89 15:38:36 EDT
Date: Tue, 4 Apr 89 15:38 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: READ-DELIMITED-LIST-EOF
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404153809.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
This issue was mentioned but was not on my list of possible topics.
No action was taken.
Since it's probably a clarification (?) and I assume it might still
come up later.
∂04-Apr-89 1242 CL-Cleanup-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 6)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:41:09 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571273; Tue 4-Apr-89 15:41:04 EDT
Date: Tue, 4 Apr 89 15:40 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 6)
To: CL-Cleanup@SAIL.Stanford.EDU
cc: DLA@JASPER.SCRC.Symbolics.COM
Message-ID: <890404154038.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say I suggested friendly amendments to change "VREF" to "AREF"
and "it none" to "none" in the NSUBSTITUTE-xxx part.
Then the amended proposal was passed 16-1.
∂04-Apr-89 1244 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-VALUE
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:24:23 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571227; Tue 4-Apr-89 15:24:18 EDT
Date: Tue, 4 Apr 89 15:23 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-COMPONENT-VALUE
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152354.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
This was deferred to the next meeting.
∂04-Apr-89 1244 CL-Cleanup-mailer Issue: SETF-MULTIPLE-STORE-VARIABLES
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:44:43 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571286; Tue 4-Apr-89 15:44:42 EDT
Date: Tue, 4 Apr 89 15:44 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SETF-MULTIPLE-STORE-VARIABLES
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404154416.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
This was on the agenda but never gotten to.
I think it might come up at the next meeting since it's mostly just a clarification.
∂04-Apr-89 1249 CL-Cleanup-mailer Issue: SYMBOL-MACROLET-SEMANTICS
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:45:39 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 571287; 4 Apr 89 15:45:32 EDT
Date: Tue, 4 Apr 89 15:45 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SYMBOL-MACROLET-SEMANTICS
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404154506.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say...
People wanted PSETQ added with SETQ in the list of things SYMBOL-MACROLET
hacks specially.
RWK wants changes to deal with *MACRO-EXPANSION-HOOK* to clarify how it gets
called when PSETQ and SETQ are used. He seemed to want it called with the
SETF expander and a consed-up SETF form. I'd rather it be called with a special
magic expander and the actual SETQ form.
RPG wants to flush SYMBOL-MACROLET altogether and have people just use
WITH-SLOTS. Many people didn't want to give up the flexibility of
SYMBOL-MACROLET.
A vote on Version 6 "as is" passed 16-2.
A straw poll was taken on the question ``should we ask RPG to draft a proposal
for flushing SYMBOL-MACROLET.'' On a 6-8 vote, we opted not to write such
a proposal. [That doesn't preclude him from doing it anyway, of course.]
∂04-Apr-89 1249 CL-Cleanup-mailer Issue: THE-AMBIGUITY
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:46:09 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571288; Tue 4-Apr-89 15:46:07 EDT
Date: Tue, 4 Apr 89 15:45 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: THE-AMBIGUITY
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404154542.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
This was on the agenda but didn't come up.
Being a clarification, I assume it might come up next meeting.
∂04-Apr-89 1252 CL-Cleanup-mailer Issue: TIME-ZONE-NON-INTEGER
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:46:43 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571290; Tue 4-Apr-89 15:46:41 EDT
Date: Tue, 4 Apr 89 15:46 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TIME-ZONE-NON-INTEGER
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404154616.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say...
We managed to waste lots of valuable time on this.
Haflich seemed to want to use incredibly large negative time zones in
order to reason about the first century A.D. or some such thing. He
asked ``Can I make the time zone be most-positive-bignum*5?'' JonL
responded ``most-positive-bignum--my favorite number!''
Moon proposed time zones be multiples of 1/3600 so that they were
even numbers of seconds. (Some people suspected this was a subtle
marketing ploy for Symbolics.) This amendment was accepted 11-0.
Pitman proposed that we limit time zone to the range [-24,24], inclusive.
The inclusive was to allow countries to disagree on which end was open,
since it was agreed that the correct value here is a largely political,
rather than technical issue. The amendment was accepted 8-5.
The full proposal with both amendments passed 18-0.
∂04-Apr-89 1253 CL-Cleanup-mailer Issue: PATHNAME-SYNTAX-ERROR-TIME
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:29:16 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571240; Tue 4-Apr-89 15:29:14 EDT
Date: Tue, 4 Apr 89 15:28 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SYNTAX-ERROR-TIME
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152844.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
This was deferred to the next meeting.
∂04-Apr-89 1256 CL-Cleanup-mailer Issue: PATHNAME-WILD
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:29:31 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571241; Tue 4-Apr-89 15:29:26 EDT
Date: Tue, 4 Apr 89 15:29 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-WILD
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152902.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
This was deferred to the next meeting.
∂04-Apr-89 1258 CL-Cleanup-mailer Issue: WITH-COMPILATION-UNIT
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:49:03 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571301; Tue 4-Apr-89 15:48:50 EDT
Date: Tue, 4 Apr 89 15:48 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: WITH-COMPILATION-UNIT
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404154825.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say...
Users wanting to write a portable DEFSYSTEM want this.
This passed 11-6 with an amendment to say it defers "warnings" rather
than "actions" and with an amendment to say it does not apply to the
COMPILE function (only to COMPILE-FILE).
∂04-Apr-89 1301 CL-Cleanup-mailer Issue: PRINT-CASE-PRINT-ESCAPE-INTERACTION
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:32:04 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 571246; 4 Apr 89 15:32:01 EDT
Date: Tue, 4 Apr 89 15:31 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PRINT-CASE-PRINT-ESCAPE-INTERACTION
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404153136.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say this was deferred from Tuesday to Thursday but then didn't
come up for discussion.
Being a clarification, I expect it to come up at the next meeting.
∂04-Apr-89 1301 CL-Cleanup-mailer Issue: EXIT-EXTENT (version 7)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 13:01:17 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571323; Tue 4-Apr-89 16:01:09 EDT
Date: Tue, 4 Apr 89 16:00 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXIT-EXTENT (version 7)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19890404200056.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
This contains the amendments that were voted in at the X3J13 meeting last week.
I also edited the rationale and the examples to make them consistent with the
amended proposal. The MINIMAL proposal here passed 11-5.
Issue: EXIT-EXTENT
References: CATCH, THROW (p 142),
BLOCK, RETURN, RETURN-FROM,
TAGBODY, GO, UNWIND-PROTECT,
Dynamic extent (CLtL p.37),
Nested dynamic extents (CLtL p.38),
Blocks can only be exited once (CLtL p.120),
Catch is disestablished just before the values
are returned (CLtL p.139).
Related issues: UNWIND-PROTECT-NON-LOCAL-EXIT is superseded
by this one.
Category: CLARIFICATION
Edit history: ... Version 5 of UNWIND-PROTECT-NON-LOCAL-EXIT, 23-May-88 ...
Version 1, 5-Sep-88, by Moon, for discussion
Version 2, 1-Oct-88, by Masinter, minor edits
Version 3, 7-Oct-88, by Moon, wording improvements
Version 4, 7-Dec-88, by Masinter, add MEDIUM from
UNWIND-PROTECT-NON-LOCAL-EXIT, discussion.
Version 5, 12-Dec-88, Masinter, clarify MINIMAL allows MEDIUM
Version 6, 8-Jan-89, Masinter, fix some bugs
Version 7, 4-Apr-89, Moon, amend per X3J13 Mar-89, and make
rationale and examples consistent with that
Problem description:
CLtL does not specify precisely when the dynamic extent (lifetime)
of a nonlocal exit such as a CATCH, BLOCK, or TAGBODY ends.
For example, at what point is it no longer possible to RETURN-FROM
a particular BLOCK?
An "exit" refers to a point from which control can be transferred.
For a THROW or RETURN-FROM, the "exit" is the corresponding CATCH
or BLOCK body. For a GO, the "exit" is the form within the TAGBODY
which was being executed at the time the GO is performed.
The extent of an exit is dynamic; it is not indefinite. The extent
of an exit begins when the corresponding form (CATCH, BLOCK or TAGBODY
clause) is entered. When the extent of an exit has ended, it is no
longer legal to return from it.
The extent of an exit is not the same thing as the scope of the
designator by which the exit is identified. For example, a BLOCK
name has lexical scope but the extent of its exit is dynamic; the
scope of a CATCH tag could differ from the extent of the CATCH's
return point. (That's part of what is at issue here.)
The ambiguity at issue arises for the case where there are transfers
of control from the cleanup clauses of an UNWIND-PROTECT.
When a transfer of control is initiated by GO, RETURN-FROM or THROW,
a variety of events occur before the transfer of control is complete.
In particular,
(a) the cleanup clauses of any intervening UNWIND-PROTECT clauses
are evaluated,
(b) intervening dynamic bindings of special variables and catch tags
are undone,
(c) intervening exits are "abandoned", i.e., their extent ends and it
is no longer legal to attempt to transfer control through them,
(d) the extent of the exit being invoked ends,
(e) control is finally passed to the target.
The order of these events is not explicit in CLtL, however. The
implementation note on p.142 gives a clue about the interweaving
of (a) and (b), but there are differing opinions about the times
at which (c) and (d) may occur. In particular,
Is it legal for an implementation to end the extent of all
intervening exits before processing the cleanup clauses of intervening
UNWIND-PROTECTs?
What is the dynamic context at the time UNWIND-PROTECT clauses are
evaluated: how is the unwinding of dynamic bindings intertwined with
evaluation of UNWIND-PROTECT cleanup clauses?
Proposal (EXIT-EXTENT:MINIMAL):
The extent of an exit being "abandoned" because it is being passed over
ends as soon as the transfer of control is initiated. That is, the
event (c) occurs at the beginning of the initiation of the transfer of
control. In the language of the implementation note on p.142, the
extent ends at the beginning of the second pass. It is an error to
attempt a transfer of control to an exit whose dynamic extent has
ended.
The event (d) occurs at the end of the transfer of control.
Otherwise, events (a) and (b)--the undoing of dynamic binding of special
variables and CATCH tags, and the execution of UNWIND-PROTECT cleanup
clauses--are performed in the order corresponding to the reverse order
in which they were established, as implied by the implementation note
on p.142. The effect of this is that the cleanup clauses of an UNWIND-PROTECT
will see the same dynamic bindings of variables and CATCH tags as were
visible when the UNWIND-PROTECT was entered.
This proposal is called "minimal" because it gives exits the smallest
extent consistent with CLtL, except that event (d) occurs later than
CLtL requires. A program that presumed a longer extent would be in
error. Implementations may support longer extents for exits than is
required by this proposal; in particular, an implementation which
allowed the larger extent of the MEDIUM proposal below would still
conform.
Proposal (EXIT-EXTENT:MEDIUM):
The events of (a), (b), (c) and (d) are interwoven in the reverse
order in which they were established. In particular, the extent of
a passed-over exit ends when control reaches a frame that was
established before the exit was established.
In particular, it is legal, during the evaluation of an UNWIND-PROTECT
cleanup form executed because of a non-local transfer of control, to
initiate a new transfer of control to an exit intervening between the
UNWIND-PROTECT and the original target; the original processing of
transfer of control is abandoned.
Examples:
;; Error under either proposal: BLOCK exits normally before RETURN
(funcall (block nil #'(lambda () (return))))
;; Error under either proposal: normal exit before GO
(let ((a nil))
(tagbody t (setq a #'(lambda () (go t))))
(funcall a))
;; Error under either proposal: TAGBODY is passed over, before GO
(funcall (block nil
(tagbody a (return #'(lambda () (go a))))))
;;returns 2 under MEDIUM and MINIMAL, was error under MINIMAL version 6
(block nil
(unwind-protect (return 1)
(return 2)))
;;returns 2 under MEDIUM, is error under MINIMAL
(block a
(block b
(unwind-protect (return-from a 1)
(return-from b 2))))
;; returns 2 under MEDIUM and MINIMAL, was error under MINIMAL version 6
(catch nil
(unwind-protect (throw nil 1)
(throw nil 2)))
;; returns 2 under MEDIUM, is error under MINIMAL
;; because the catch of B is passed over by
;; the first THROW, hence portable programs must assume its dynamic extent
;; is terminated. The binding of the catch tag is not yet disestablished
;; and therefore it is the target of the second throw.
(catch 'a
(catch 'b
(unwind-protect (throw 'a 1)
(throw 'b 2))))
;; the following was an error under MINIMAL version 6; the extent of
;; the inner catch terminates as soon as the THROW commences, even
;; though it remains in scope. Thus, the THROW of :SECOND-THROW
;; sees the inner CATCH, but its extent has ended.
;; under MEDIUM and MINIMAL version 7,
;; it prints "The inner catch returns :SECOND-THROW"
;; and then returns :OUTER-CATCH.
(catch 'foo
(format t "The inner catch returns ~s.~%"
(catch 'foo
(unwind-protect (throw 'foo :first-throw)
(throw 'foo :second-throw))))
:outer-catch))
;; Following returns 10 under either proposal. The inner
;; CATCH of A is passed over, but because that CATCH
;; is disestablished before the THROW to A is executed,
;; it isn't seen.
(catch 'a
(catch 'b
(unwind-protect (1+ (catch 'a (throw 'b 1)))
(throw 'a 10))))
;; Following is an error under MINIMAL because the extent of
;; the (CATCH 'BAR ...) exit ends when the (THROW 'FOO ...)
;; commences.
;; Under MEDIUM, the pending exit to tag FOO is discarded by the
;; second THROW to BAR and the value 4 is transferred to
;; (CATCH 'BAR ...), which returns 4. The (CATCH 'FOO ...)
;; then returns the 4 because its first argument has returned
;; normally. XXX is not printed.
(CATCH 'FOO
(CATCH 'BAR
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
;; Following returns 4 under either proposal; XXX is not printed.
;; The (THROW 'FOO ...) has no effect on the scope of the BAR
;; catch tag or the extent of the (CATCH 'BAR ...) exit.
(CATCH 'BAR
(CATCH 'FOO
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
;;The following are legal and print 5 under either proposal:
(block nil
(let ((x 5))
(declare (special x))
(unwind-protect (return)
(print x))))
(block nil
(let ((x 5))
(declare (special x))
(unwind-protect
(if (test) (return))
(print x))))
Rationale:
For MINIMAL: Giving exits the smallest extent consistent with CLtL
maximizes freedom for implementations; there are few applications,
if any, that require a longer extent. Delaying event (d) until
the transfer of control is completed allows multiple attempts to
exit from a single exit, if the first attempt is interrupted,
possibly by an error.
For MEDIUM: Giving exits a longer extent has cleaner semantics.
Current practice:
Both implementations of Symbolics Genera (3600 and Ivory) end the extent
of a target BLOCK or CATCH at the moment the values are returned, and
end the extent of a passed-over exit at the moment the THROW, RETURN, or
GO commences. This choice of extent maximizes efficiency within the
particular stack structure used by these implementations, by avoiding
the need to retain the control information needed to use a passed over
exit through the transfer of control. Genera signals an error if an
attempt is made to use an exit that has been passed over.
In some implementations, it is possible for a throw or non-local exit
to be effectively "stopped" by an UNWIND-PROTECT cleanup clause that
performs a non-local transfer of control to a passed-over exit.
Some implementations crash or otherwise generate garbage code for
non-local exits from cleanup clauses of UNWIND-PROTECT.
Cost to Implementors:
No currently valid implementation will be made invalid by the MINIMAL
proposal. Some implementors may wish to add error checks if they
do not already have them.
MEDIUM would have a high cost for those implementations that currently
have shorter extent.
Cost to Users:
Most user programs don't do this, so there is likely little cost
of converting existing code in any case. In any case, current implementations
differ enough that this issue ostensibly does not
affect current portable programs. Some users might have code that
relies on the "unstoppable loops" that can be created with the MEDIUM
proposal.
Benefits:
Either proposal would make Common Lisp more precisely defined.
Cost of non-adoption :
The semantics of exits will remain ambiguous.
Esthetics:
Precisely specifying the meaning of dynamic extent improves the language.
Leaving implementations free to implement a longer extent if they choose
can be regarded as unesthetic, but consistent with Common Lisp philosophy.
Having a CATCH that is in scope even though its extent has ended may
seem unesthetic, but it is consistent with how BLOCK behaves.
Discussion:
This issue is controversial. It was first discussed under the issue
named UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT. The issue was recast as
the more global one of "extent of exits" rather than the specific
one of "what happens if a cleanup in an UNWIND-PROTECT does a non-
local exit", but the problem cases for both topics are the same.
The goal of the MINIMAL proposal is to clarify the ambiguity in CLtL while
minimizing changes to the current situation. The MEDIUM proposal
defines the extent of an exit to end at the last moment possible
within some particular reference implementation. It has
a cost to implementors whose implementation is not identical to the
reference implementation. Another alternative proposal, not considered
here, would duck the issue by outlawing all non-local exits from UNWIND-PROTECT
cleanup forms. That alternative would have a substantial cost to some users.
Scheme is cleaner: it avoids this issue by specifying that the extent
of an exit never ends.
An argument for the MEDIUM proposal was made based on the example:
(block foo
(block bar
(unwind-protect
(return-from foo 'foo)
(return-from bar 'bar))))
Since there is no reason for FOO and BAR not to be treated interchangeably,
calling this an error would be inappropriate.
It was argued that the MINIMAL proposal is equivalent to practically
outlawing non-local exits from UNWIND-PROTECT cleanup clauses, because
there is no general way to determine the target of the non-local exit
that caused the cleanup clause to be invoked.
The following example was offered as an argument against MINIMAL. Given:
(block nil
(handler-case
(unwind-protect (return)
(error "foo")) ;probably an error, under the proposal
(error ()
(print "foo"))))
If the ERROR handler has the same scope and extent a CATCH in the same place
would have (and that seems reasonable, though I'm not certain that the
condition system specifically requires that interpretation), then the handler
will be apparent to the call to ERROR, but will no longer be a valid target
(its extent was exited by the RETURN in the UNWIND-PROTECT body).
The extent of an object with dynamic extent is the extent of the form
which created it. Code which is executed "within" that form is within
the extent of the object(s). This applies to all dynamic objects, such
as special variable bindings, not just exits. Actually, I think the intent
of the implementation note on p.142 is fairly clear and supports this
interpretation. The supposedly ambiguous use of "frame" should be read
as something like "form which establishes a dynamic extent". It might be
clearer if the last sentence were changed to read something like:
"On the second pass the stack is actually unwound. Each form which establishes
a dynamic extent is undone in reverse order of creation until the matching
CATCH is reached. The meaning of undoing a form depends on the type of form.
For UNWIND-PROTECT, it means executing the cleanup forms. For CATCH it means
removing the CATCH tag. For dynamic bindings it means undoing the binding,
restoring the previous saved value. {This is not an exhaustive listing of the
possibilities.}"
∂04-Apr-89 1301 CL-Cleanup-mailer Issue: PRINT-CIRCLE-SHARED
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:32:56 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571250; Tue 4-Apr-89 15:32:49 EDT
Date: Tue, 4 Apr 89 15:32 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PRINT-CIRCLE-SHARED
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404153225.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
This was deferred from Tuesday to Thursday but then didn't come up
for discussion.
Since some people (myself included, I think) consider this almost
a clarification, my feeling is that it could still come up at the
next meeting.
∂04-Apr-89 1304 CL-Cleanup-mailer Issue: REAL-NUMBER-TYPE
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:39:35 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571267; Tue 4-Apr-89 15:39:27 EDT
Date: Tue, 4 Apr 89 15:38 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REAL-NUMBER-TYPE
To: CL-Cleanup@SAIL.Stanford.EDU
cc: Cassels@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <890404153856.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say...
Barmar moved we accept ``both proposals'' (since one was obviously trying
to include the other, but the wording didn't really make that clear).
The motion to approve both passed 12-3.
∂04-Apr-89 1309 CL-Cleanup-mailer Issue: REQUIRE-PATHNAME-DEFAULTS
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:41:57 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571274; Tue 4-Apr-89 15:41:50 EDT
Date: Tue, 4 Apr 89 15:41 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404154124.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say...
A motion to reconsider this issue was made.
The motion to reconsider passed 5-4.
A motion was made to deprecate rather than to remove.
Pitman proposed an amendment to make these macros instead of functions,
thinking that REQUIRE and PROVIDE were part of the magic functions we
were trying to eliminate. He tried to withdraw the motion to amend
when someone observed that they are not supposed to be specially treated
but others still wanted them to be macros for some reason. Anyway, the
amendment failed on a vote of 4-11.
The original motion to deprecate instead of remove was voted on.
The first count was 7-7, but someone asked for a recount.
The next count was 7-8, but someone was late raising his hand and didn't
think his vote had counted right.
The next vote was 8-7. At this point, Pitman requested a roll call vote
so there would be no dispute later.
The results were:
IBM No
DEC Yes
RWK(!) Yes
TI No
IIM Yes
Univ of Utah No
Apple Yes
Franz Yes
Think Yes
Encore Yes
Honeywell No
Johnson Controls No
MCC No
Xerox No
Lucid Yes
SMBX No
The motion failed 8-8, so the result voted on at the previous meeting stands.
∂04-Apr-89 1309 CL-Cleanup-mailer Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:48:24 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571297; Tue 4-Apr-89 15:48:21 EDT
Date: Tue, 4 Apr 89 15:47 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404154756.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Deferred until next meeting.
There was some ``off-line'' discussion of slot-unbound with no real resolution.
That part of the issue promises to be a controversial one.
Moon seems to think that one idea that had some support is to say that the
system-defined method "should signal an error", depending on the safety level
of the original call to SLOT-VALUE, so the generic function is only called if
the SLOT-VALUE is safe or user-defined methods might be applicable. I haven't
had time to decide whether I understand this enough to either agree or disagree.
∂04-Apr-89 1309 CL-Cleanup-mailer Issue: TYPE-OF-UNDERCONSTRAINED
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:47:07 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571292; Tue 4-Apr-89 15:46:55 EDT
Date: Tue, 4 Apr 89 15:46 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TYPE-OF-UNDERCONSTRAINED
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404154630.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
Some people had some concerns about a previous version of this that passed.
We wanted to reconsider this, but didn't have the right hardcopy.
No action was taken. This will probably come up next meeting.
∂04-Apr-89 1324 CL-Cleanup-mailer issue DYNAMIC-EXTENT-FUNCTION, version 1
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 13:24:20 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571355; Tue 4-Apr-89 16:23:51 EDT
Date: Tue, 4 Apr 89 16:23 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue DYNAMIC-EXTENT-FUNCTION, version 1
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8904041727.AA19101@defun.utah.edu>
Message-ID: <19890404202338.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comments on current practice:
This is very different from Symbolics Genera current practice, which
I would describe as follows:
First, if a function A has a DYNAMIC-EXTENT declaration for one of its
parameters F, and a caller of A passes a function B as the argument
corresponding to the parameter F, then B is used in a "downward" way.
Calling a function directly or via FUNCALL or APPLY is a "downward" use
too. If every use of a function is "downward", then the compiler
implements the function with dynamic extent (provided the function is
not globally named, but is only locally named or not named at all, i.e.
defined with FLET, LABELS, or LAMBDA). We currently use a different
name for the declaration, instead of DYNAMIC-EXTENT, but that is
unimportant.
Does the compiler committee's model of compilation permit compilation of
one function to be affected by declarations in the current definition of
another function that it calls? I hope so.
Second, if a function has a SYS:DOWNWARD-FUNCTION declaration in front of
its body, then the function is implemented with dynamic extent regardless
of whether the compiler thinks all uses are "downward". This feature is
used less often than the first feature, but is still used pretty often.
An example would be
(funcall (computation-that-returns-a-function)
(function (lambda (...)
(declare (sys:downward-function))
...))
...other args...)
Here the function being called is not known at compile time, so there
is no place from which to obtain a DYNAMIC-EXTENT declaration. In
your proposal, the declaration cannot be made unless the function is
given a name, so this example would have to be rewritten as:
(flet ((dummy-name (...)
...))
(declare (dynamic-extent-function dummy-name))
(funcall (computation-that-returns-a-function)
(function dummy-name)
...other args...))
Third, there is a variation of the first feature by which a function can
declare that all of its arguments are used "downward"; this is
especially useful for declaring arguments that are elements of a list
that is the value of an &rest parameter, since there is no parameter
name corresponding to those arguments. We do this by using * instead of
a parameter name, but I don't see any way to map that into the
DYNAMIC-EXTENT declaration. However, if we were willing to say that the
&rest list also had to have dynamic extent in this case, then a
DYNAMIC-EXTENT declaration of the &rest parameter would imply downward
use of the functions, since otherwise they would not be OIPs (in the
language of the amended DYNAMIC-EXTENT proposal that we just passed).
So I don't think we need this third feature.
The fact that your proposal is different from Symbolics Genera current
practice doesn't mean the proposal is wrong, after all it is also very
different from the current practices of the two implementations listed
in the proposal. But we should think hard about dynamic extent for
anonymous lambdas, which can be quite important in practice.
On a sillier note, should we minimize proliferation of names by
replacing
(declare (dynamic-extent-function name))
with
(declare (dynamic-extent #'name)) ?
This is a serious proposal, although I suspect that some people
will think it is a stupid idea.
∂04-Apr-89 1531 CL-Cleanup-mailer Issue: COPY-SYMBOL-PRINT-NAME (not COPY-SYMBOL-COPY-PRINT-NAME)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 15:31:00 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571454; Tue 4-Apr-89 18:30:52 EDT
Date: Tue, 4 Apr 89 18:30 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COPY-SYMBOL-PRINT-NAME (not COPY-SYMBOL-COPY-PRINT-NAME)
To: CL-Cleanup@SAIL.Stanford.EDU
Supersedes: <890404113419.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <890404183026.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Tue, 4 Apr 89 11:34 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COPY-SYMBOL-COPY-PRINT-NAME
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404113419.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say this passed unanimously.
The issue name was COPY-SYMBOL-PRINT-NAME, of course.
Sorry for the typo. Hope this didn't confuse anyone.
∂04-Apr-89 2058 CL-Cleanup-mailer issue DYNAMIC-EXTENT-FUNCTION, version 1
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Apr 89 20:58:35 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA17233g; Tue, 4 Apr 89 20:52:50 PDT
Received: by bhopal id AA11925g; Tue, 4 Apr 89 20:59:22 PDT
Date: Tue, 4 Apr 89 20:59:22 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8904050359.AA11925@bhopal>
To: sandra%defun@cs.utah.edu
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Tue, 4 Apr 89 11:27:21 MDT <8904041727.AA19101@defun.utah.edu>
Subject: issue DYNAMIC-EXTENT-FUNCTION, version 1
re: Introduce a new declaration called DYNAMIC-EXTENT-FUNCTION. This is
identical to the DYNAMIC-EXTENT declaration, except that the
arguments name functions instead of variables.
This is not sufficiently clear for a "specification". I think you should
at least talk about how the DYNAMIC-EXTENT-FUNCTION declaration only applies
to lexical functions defined via FLET and LABELS, and is not to be used in
a proclamation.
Additionally, you will have to say, for a form like:
(locally (declare (dynamic-extent-function f g))
(labels ((f (x) ...)
(g (y) ...)
(h (z) ...))
(declare <more-declarations>)
...))
whether or not the declaration in the LOCALLY is to apply to the two
functions, or whether it has to be supplied in the place indicated by
<more-declarations> [my first inclination is that it doesn't apply,
since similar program structure for type declarations wouldn't apply.]
Similarly, you will have to say whether or not there is such a thing
as a "free" dynamic-extent-function declaration. E.g., what does
the following mean:
(flet ((f (x) ...))
(funcall f gobbledygook)
(locally (declare (dynamic-extent-function f))
(cogitate #'f))
t)
Here, my inclination is that unless the dynamic-extent-function declaration
is applied to the name binding, it is useless to the compiler. It's a bit
like allowing the compiler to represent FLOATs in specialized storage,
providing it knows that during the entire lifetime of the variable --
including the binding time -- the value will only be FLOAT [hence, it can,
e.g., use the flonum pdl instead of "boxing up" the value in the heap]
Finally, you have to say how you handle a case like:
(mapcar (the dynamic-extent-function #'(lambda (x) <capture-stuff>))
...)
and if so, how to specify the particular dynamic scope of interest.
Or, maybe you don't want to handle "anonymous" lexical functions. [By
the bye, I realize that 'dynamic-extent-function' isn't a type -- I
only wanted to illustrate the problem for "anonymous" functions.]
If the places where the two declarations DYNAMIC-EXTENT-FUNCTION and
DYNAMIC-EXTENT can be legitimately used don't overlap, then I don't
see anything wrong with using the same name. E.g.,
(let ((x (make-list n :initial-element 0)))
(declare (dynamic-extent x))
(labels ((f (y z) ...))
(declare (dynamic-extent f))
. . . ))
should be unambiguous.
-- JonL --
P.S. The fact that I'm replying to a msg sent today doesn't mean that
I'm not still 4 weeks behind (in general) in mail reading.
∂05-Apr-89 0710 CL-Cleanup-mailer Re: issue DYNAMIC-EXTENT-FUNCTION, version 1
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 5 Apr 89 07:10:33 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA14298; Wed, 5 Apr 89 08:10:27 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA19876; Wed, 5 Apr 89 08:10:22 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904051410.AA19876@defun.utah.edu>
Date: Wed, 5 Apr 89 08:10:21 MDT
Subject: Re: issue DYNAMIC-EXTENT-FUNCTION, version 1
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 4 Apr 89 16:23 EDT
> Date: Tue, 4 Apr 89 16:23 EDT
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>
> Does the compiler committee's model of compilation permit compilation of
> one function to be affected by declarations in the current definition of
> another function that it calls? I hope so.
Issue COMPILE-ENVIRONMENT-CONSISTENCY talks about situations in which
the compiler is allowed to assume that functions defined in the
compiletime environment retain the same definitions at runtime. I
don't see anything wrong with applying this technique in those
situations.
> Second, if a function has a SYS:DOWNWARD-FUNCTION declaration in front of
> its body, then the function is implemented with dynamic extent regardless
> of whether the compiler thinks all uses are "downward". This feature is
> used less often than the first feature, but is still used pretty often.
I vaguely remembered seeing this in some ancient Symbolics
documentation. It seems a little strange to me to have a declaration
that is only valid in one particular place, but this would indeed take
care of the problem with anonymous lambdas.
> On a sillier note, should we minimize proliferation of names by
> replacing
>
> (declare (dynamic-extent-function name))
>
> with
>
> (declare (dynamic-extent #'name)) ?
I wouldn't have any strong objection to doing this, but maybe I'm
being silly too. :-)
-Sandra
-------
∂05-Apr-89 0721 CL-Cleanup-mailer Re: issue DYNAMIC-EXTENT-FUNCTION, version 1
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 5 Apr 89 07:21:47 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA14975; Wed, 5 Apr 89 08:21:43 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA19890; Wed, 5 Apr 89 08:21:40 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904051421.AA19890@defun.utah.edu>
Date: Wed, 5 Apr 89 08:21:39 MDT
Subject: Re: issue DYNAMIC-EXTENT-FUNCTION, version 1
To: Jon L White <jonl@lucid.com>
Cc: sandra%defun@cs.utah.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: Jon L White <jonl@lucid.com>, Tue, 4 Apr 89 20:59:22 PDT
I don't want to downplay your concerns, but it ought to be pointed out
that all of the problems you mention also apply to the DYNAMIC-EXTENT
declaration proposal that we have already accepted. (The only
difference between the two is that DYNAMIC-EXTENT declarations apply
to variable bindings and DYNAMIC-EXTENT-FUNCTION declarations apply to
function bindings.) Maybe I'm extrapolating beyond what was actually
stated in issue DECLARATION-SCOPE, but there's no confusion in my mind
about the scope of these two particular declarations, or what it means
for them to appear "free".
-Sandra
-------
∂05-Apr-89 0805 CL-Cleanup-mailer Re: Issue: LISP-SYMBOL-REDEFINITION
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 5 Apr 89 08:05:21 PDT
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA05665; Wed, 5 Apr 89 11:05:04 -0400
Received: from localhost by mist. (4.0/SMI-4.0)
id AA04672; Wed, 5 Apr 89 11:06:53 EDT
Message-Id: <8904051506.AA04672@mist.>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: "sandra%defun@SAIL.Stanford.EDU"@multimax.encore.com,
CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: Issue: LISP-SYMBOL-REDEFINITION
In-Reply-To: Your message of Tue, 04 Apr 89 14:58:00 -0400.
Date: Wed, 05 Apr 89 11:06:51 EDT
From: Dan L. Pierson <pierson@mist.encore.com>
Ultimately, I have written in my notes that we voted on
``proposal replaced by RPG, item 8 struck, w/ Sandra's prohibition
to trace local functions''
and that it passed 14-3.
My note agree with this interpretation.
∂05-Apr-89 0848 CL-Cleanup-mailer issue DYNAMIC-EXTENT-FUNCTION, version 1
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 5 Apr 89 08:47:55 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571732; Wed 5-Apr-89 11:47:23 EDT
Date: Wed, 5 Apr 89 11:47 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue DYNAMIC-EXTENT-FUNCTION, version 1
To: Jon L White <jonl@lucid.com>
cc: sandra%defun@cs.utah.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: <8904050359.AA11925@bhopal>
Message-ID: <19890405154713.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
It's my belief that a close reading of the GLS and KMP amendment to
DYNAMIC-EXTENT (which was passed out at the meeting last week and
was unanimously adopted by X3J13 provides an unambiguous answer to
each of your concerns.
∂05-Apr-89 1159 CL-Cleanup-mailer Issue: DYNAMIC-EXTENT (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 5 Apr 89 11:59:13 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571894; Wed 5-Apr-89 14:59:05 EDT
Date: Wed, 5 Apr 89 14:58 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DYNAMIC-EXTENT (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890405145837.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
This was approved but it was so piecemeal it was hard to read so I produced
a new copy for reference.
I made the changes per our meeting and also changed some usages of
"proper part" in the examples to refer to OIP's instead. I trimmed
from the Discussion and Additional Discussion those things which seemed
no longer relevant.
I hope this fairly represents the current state of what was approved.
-----
Forum: Cleanup
Issue: DYNAMIC-EXTENT
References: Scope and Extent
Category: ADDITION
Edit history: 27-Jun-88, Version 1 by Pitman (as issue STACK-LET)
15-Nov-88, Version 2 by Pitman (issue renamed, major revision)
11-Jan-89, Version 3 by Masinter (Moon's proposal)
05-Apr-89, Version 4 by Pitman and Steele (changes per X3J13)
Related-Issues: REST-ARGUMENT-EXTENT, WITH-DYNAMIC-EXTENT
Status: Accepted DYNAMIC-EXTENT:X3J13-MAR-89, 30-Mar-89 on a 17-0 vote.
Problem Description:
Sometimes a programmer knows that a particular data structure
will have only dynamic extent. In some implementations, it is
possible to allocate such structures in a way that will make them
easier to reclaim than by general purpose garbage collection
(eg, on the stack or in some temporary area). Currently, however,
there is no way to request the use of such an allocation mechanism.
Proposal (DYNAMIC-EXTENT:NEW-DECLARATION):
Introduce a new declaration called DYNAMIC-EXTENT. The arguments to
this declaration are names of variables.
It is permissible for an implementation to simply ignore this declaration.
In implementations which do not ignore it, the compiler (or interpreter)
is free to make whatever optimizations are appropriate given this
information; the most common optimization is to stack-allocate the
initial value of the object. What data types (if any) can have dynamic
extent will can vary from implementation to implementation.
Definition: Object <x> is an ``otherwise inaccessible part'' (OIP)
of <y> iff making <y> inaccessible would make <x> inaccessible.
(Note that every object is an OIP of itself.)
Suppose that construct <c> contains a DYNAMIC-EXTENT declaration for
variable <v> (which need not be bound by <c>). Consider the values
<w1>, ..., <wN> taken on by <v> during the course of some execution of
<c>. The declaration asserts that if object <x> is an OIP of <wI>
when <wI> ever becomes the value of <v>, then just after execution of
<c> terminates <x> will be either inaccessible or still an OIP of <v>.
If the assertion is ever violated, the conseqeuences are undefined.
Examples:
Since stack allocation of the initial value entails knowing at the
object's creation time that the object can be stack-allocated, it is
not generally useful to declare DYNAMIC-EXTENT for variables for
which have no lexically apparent initial value. For example,
(DEFUN F ()
(LET ((X (LIST 1 2 3)))
(DECLARE (DYNAMIC-EXTENT X))
...))
would permit those compilers which wish to do so to stack-allocate the
list in X. However,
(DEFUN G (X) (DECLARE (DYNAMIC-EXTENT X)) ...)
(DEFUN F () (G (LIST 1 2 3)))
could not typically permit a similar optimization in G because it would
be a modularity violation for the compiler to assume facts about G from
within F. Only an implementation which was willing to be responsible for
recompiling F if G's definition changed incompatibly could stack-allocate
the list argument to G in F.
Other interesting cases are:
(PROCLAIM '(INLINE G))
(DEFUN G (X) (DECLARE (DYNAMIC-EXTENT X)) ...)
(DEFUN F () (G (LIST 1 2 3)))
and (DEFUN F ()
(FLET ((G (X) (DECLARE (DYNAMIC-EXTENT X)) ...))
(G (LIST 1 2 3))))
where some compilers might realize the optimization was possible and others
might not.
An interesting variant of this is the so-called `stack allocated rest list'
which can be achieved (in implementations supporting the optimization) by:
(DEFUN F (&REST X)
(DECLARE (DYNAMIC-EXTENT X))
...)
Note here that although the initial value of X is not explicit, the F
function is responsible for assembling the list X from the passed arguments,
so the F function can be optimized by the compiler to construct a
stack-allocated list instead of a heap-allocated list in implementations
which support such.
In
(LET ((X (LIST 'A1 'B1 'C1))
(Y (CONS 'A2 (CONS 'B2 (CONS 'C2 NIL)))))
(DECLARE (DYNAMIC-EXTENT X Y))
...)
The OIP's of X are three conses, and the OIP's of Y are three other
conses. None of the symbols A1, B1, C1, A2, B2, C2, or NIL is an
OIP of X or Y. However, if a freshly allocated uninterned symbol had
been used, it would have been an OIP.
- - - - - - - -
(DOTIMES (I N)
(DECLARE (DYNAMIC-EXTENT I))
This is particularly instructive. Since I is an integer by the
definition of DOTIMES, but EQ and EQL are not necessarily equivalent for
integers, what are the OIP's of I, which this declaration
requires the body of the DOTIMES not to "save"? If the value of I is 3,
and the body does (SETQ FOO 3), is that an error? The answer is no, but
the interesting thing is that it depends on the implementation-dependent
behavior of EQ on numbers. In an implementation where EQ and EQL are
equivalent for 3, then 3 is not an OIP because (EQ I (+ 2 1)) is true,
and therefore there is another way to access the object besides
going through I. On the other hand, in an implementation where EQ and
EQL are not equivalent for 3, then the particular 3 that is the value of
I is an OIP, but any other 3 is not. Thus (SETQ FOO 3) is valid
but (SETQ FOO I) is erroneous. Since (SETQ FOO I) is erroneous in some
implementations, it is erroneous in all portable programs, but some other
implementations may not be able to detect the error.
- - - - - - - -
(LET ((X (LIST 1 2 3)))
(DECLARE (DYNAMIC-EXTENT X))
(PRINT X)
NIL)
PRINT does not "save" any part of its input.
This prints (1 2 3)
- - - - - - - -
(DO ((L (LIST-ALL-PACKAGES) (CDR L)))
((NULL L))
(DECLARE (DYNAMIC-EXTENT L))
(PRINT (CAR L)))
prints all packages; none of the newly-allocated list structures are saved.
- - - - - - - -
(DEFUN ADD (&REST X) (DECLARE (DYNAMIC-EXTENT X)) (APPLY #'+ X))
(ADD 1 2 3) => 6
I.e., useful way to declare that &REST lists have dynamic extent
- - - - - - - -
(DEFUN ZAP (X Y Z)
(DO ((L (LIST X Y Z) (CDR L)))
((NULL L))
(DECLARE (DYNAMIC-EXTENT L))
(PRIN1 (CAR L))))
(ZAP 1 2 3)
prints 123
- - - - - - - -
(DEFUN ZAP (N M)
;; Computes (RANDOM (+ M 1)) at relative speed of roughly O(N).
;; It may be slow, but with a good compiler at least it
;; doesn't waste much heap storage. :-)
(LET ((A (MAKE-ARRAY N)))
(DECLARE (DYNAMIC-EXTENT A))
(DOTIMES (I N)
(DECLARE (DYNAMIC-EXTENT I))
(SETF (AREF A I) (RANDOM (+ I 1))))
(AREF A M)))
(< (ZAP 5 3) 3) => T
- - - - - - - -
The following are in error, since the value of X is used outside of its
extent:
(LENGTH (LIST (LET ((X (LIST 1 2 3))) (DECLARE (DYNAMIC-EXTENT X)) X)))
(PROGN (LET ((X (LIST 1 2 3))) (DECLARE (DYNAMIC-EXTENT X)) X)
NIL)
- - - - - - - -
Rationale:
This permits a programmer to offer advice to an implementation about
what may be stack-allocated for efficiency.
It may be difficult or impossible for a compiler to infer this
same information statically.
Since a number of implementations offer this capability and there
is demand from users for access to the capability, this ``codifies
existing practice.''
Because this approach is purely lexical, it does not interact badly with
other programs in the way that the macro WITH-DYNAMIC-EXTENT (see issue
by same name) would.
Current Practice:
Symbolics Genera and Symbolics Cloe offer stack allocation, though not
in this strategy.
[KMP thinks that] Lucid supports the proposal.
Cost to Implementors:
No cost is forced since implementations are permitted to simply
ignore the DYNAMIC-EXTENT declaration.
Cost to Users:
None. This change is upward compatible.
There may be some hidden costs to debugging using this declaration (or any
feature which permits the user to access dynamic extent objects without
the compiler proving that they are appropriate). If the user misdeclares
something and returns a pointer into the stack (or stores it in the heap),
an undefined situation may result and the integrity of the Lisp storage
mechanism may be compromised. Debugging these situations may be tricky,
but users who have asked for this feature have indicated a willingness
to deal with such costs. Nevertheless, the perils should be clearly
documented and casual users should not be encouraged to use this
declaration.
Cost of Non-Adoption:
Some portable code would be forced to run more slowly (due to
GC overhead), or to use non-portable language features.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
This declaration allows a fairly low level optimization to work
by asking the user to provide only very high level information.
The alternatives (sharpsign conditionals, some of which may
lead to more bit-picky abstractions) are far less aesthetic.
Discussion:
A previous version of this proposal suggested primitives STACK-LET
and STACK-LET*. Consensus was that the more general declaration facility
would be more popular.
Moon came up with a description of something called a "proper part" which
Steele formalized into the idea of an "otherwise inaccessible part". The
two are essentially interchangeable, but Steele's description was more
rigorous.
KMP: ... it still raises the question of whether we should define
per-function for every CL function whether any of the arguments is
permitted to be "saved" so that CL programs don't get any funny
surprises. If we don't, it ends up being implementor's discretion how
to resolve cases ... and everyone might not agree that all cases are
... obvious ...
JonL: PDP10 MacLisp had a similar problem w.r.t pdlnums. That is why
"identity" functions were so troublsome for it -- in order to
return a guaranteed safe value, it typically had to copy it's
pdlnum argument, thereby making some cases of "fast arithmetic"
code much worse than interpreted code! [Remember PRINT in MacLisp?
it returns T rather than it's argument for just this reason.]
It is necessary for an optimizing compiler to know something about
what happens to the data it passes along to "system" functions; for
example, it could assume that GET doesn't clobber the list given
to it, nor does it retain pointers to any part of it [what was the
terminology in the revised proposal? "saved"? and "proper part"?]
The issue LISP-SYMBOL-REDEFINITION might help here, in that an
implementation's compilers could depend upon it's own internal
database. But it wouldn't hurt at all to have some of these
requirements "up front" in the standard.
It was generally agreed that we would also like to consider a proposal
on dynamic extent functions at the next meeting. (Sandra said she would
prepare one, and has already done so. See issue DYNAMIC-EXTENT-FUNCTION.)
∂05-Apr-89 1206 CL-Cleanup-mailer Issue: DYNAMIC-EXTENT (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 5 Apr 89 12:06:04 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571908; Wed 5-Apr-89 15:06:07 EDT
Date: Wed, 5 Apr 89 15:05 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DYNAMIC-EXTENT (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890405145837.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <890405150540.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Sigh. As you can probably tell, I meant to change the name of the
proposal from NEW-DECLARATION to X3J13-MAR-89 like Masinter's been
doing and I only did it half-way. There's only one proposal so
please don't be confused. Anyway, the text is right so I'm gonna
leave it...
∂05-Apr-89 1731 CL-Cleanup-mailer issue DYNAMIC-EXTENT-FUNCTION, version 1
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 5 Apr 89 17:31:35 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00786g; Wed, 5 Apr 89 17:25:35 PDT
Received: by bhopal id AA04722g; Wed, 5 Apr 89 17:32:08 PDT
Date: Wed, 5 Apr 89 17:32:08 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8904060032.AA04722@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: sandra%defun@cs.utah.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Wed, 5 Apr 89 11:47 EDT <19890405154713.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: issue DYNAMIC-EXTENT-FUNCTION, version 1
re: It's my belief that a close reading of the GLS and KMP amendment to
DYNAMIC-EXTENT (which was passed out at the meeting last week and
was unanimously adopted by X3J13 provides an unambiguous answer to
each of your concerns.
Well, the difficulty centers on how one interprets the word "identical"
in Sandra's proposal. I would invite you to make your interpretation,
and put it into unambiguous words, explicitly in this proposal.
By the bye, do you agree that a single declaration name -- DYNAMIC-EXTENT
-- is satisfactory for both contexts? A reasonable alternative might
simply be to amend the previously passed proposal to include the function
context.
-- JonL --
∂05-Apr-89 2203 CL-Cleanup-mailer issue DYNAMIC-EXTENT-FUNCTION, version 1
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 5 Apr 89 22:03:16 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00980g; Wed, 5 Apr 89 21:57:29 PDT
Received: by bhopal id AA05644g; Wed, 5 Apr 89 22:03:57 PDT
Date: Wed, 5 Apr 89 22:03:57 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8904060503.AA05644@bhopal>
To: sandra%defun@cs.utah.edu
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Wed, 5 Apr 89 08:21:39 MDT <8904051421.AA19890@defun.utah.edu>
Subject: issue DYNAMIC-EXTENT-FUNCTION, version 1
re: . . .all of the problems you mention also apply to the DYNAMIC-EXTENT
declaration proposal that we have already accepted. (The only
difference between the two is that DYNAMIC-EXTENT declarations apply
to variable bindings and DYNAMIC-EXTENT-FUNCTION declarations apply to
function bindings.)
This can't be true -- for example, there is no such thing as
"anonymous variables" in the way that lambda-forms are anonymous
functions. And as Moon's recounting of the current Symbolics model
shows, downward lambdas can be very important.
However, I was mostly concerned about the possibility that two
readers might interpret your wording "identical" in somwhat
non-identical ways.
-- JonL --
∂06-Apr-89 1115 CL-Cleanup-mailer Condensed summary of CL Cleanup meeting results
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 6 Apr 89 11:15:35 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 572595; Thu 6-Apr-89 14:15:30 EDT
Date: Thu, 6 Apr 89 14:14 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Condensed summary of CL Cleanup meeting results
To: CL-Cleanup@SAIL.Stanford.EDU
cc: chapman%aitg.dec@decwrl.dec.com
Message-ID: <890406141456.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Kathy Chapman asked for the information that was in my last burst of
messages in some sort of `summary' form. I had chosen to send out
individual messages because I assumed most people like myself who were
doing per-topic filing would find that simpler. But for those who are
just auditing this stuff and deleting it, here's my summary.
Just a reminder though -- these are just my notes and do not necessarily
represent the official story if it turns out there are discrepancies.
-----
ADJUST-ARRAY-NOT-ADJUSTABLE - Deferred
BREAK-ON-WARNINGS-OBSOLETE - Passed
CLOS-CONDITIONS - Passed
CLOS-MACRO-COMPILATION - Tabled
CLOSED-STREAM-OPERATIONS -
Motion to replace v7 with v5 passed unamended
COERCE-INCOMPLETE - Withdrawn
COMMON-TYPE - Passed
COMPLEX-RATIONAL-RESULT - Passed
CONDITION-RESTARTS - Deferred
COPY-SYMBOL-COPY-PLIST - Passed
COPY-SYMBOL-COPY-PRINT-NAME - Passed
DECLARE-FUNCTION-AMBIGUITY -
An incredibly weird vote on the question ``How many favor saying it passed
at the last meeting?'' passed N-0-M.
DEFINE-OPTIMIZER - Failed
There is new information which leads me to believe this might come up
again at the next meeting.
DEFMACRO-LAMBDA-LIST -
There were hardcopy amendments distributed.
My notes say that we approved amendments A & B (``permit all four'')
and we added an amendment that said that &ENVIRONMENT would not be
duplicated in a DEFMACRO lambda-list.
The amended proposal was passed N-0-1.
DESCRIBE-UNDERSPECIFIED -
An amendment was made (I think by Barrett) to make DESCRIBE deal with
its second argument in the same way as PRINT does (that is, permitting
arguments of NIL and T).
The amended proposal passed 15-0.
DESTRUCTURING-BIND
Discussion on this was broken over two days with quite a number of
possible amendments discussed. Pitman came up with a written set of
amendments for Thursday which were discarded because Moon submitted a
revised proposal (consistent with those amendments, and adding at least
one other feature not covered in those separate amendments) on Thursday.
The revised proposal was v3, already mailed.
Moon's revised proposal was voted on, and passed 15-1.
DYNAMIC-EXTENT -
Steele and Pitman drafted a revised proposal over lunch Thursday
which passed 17-0.
EQUALP-GENERIC - Withdrawn
ERROR-CHECKING-IN-NUMBERS-CHAPTER - Deferred
ERROR-NOT-HANDLED -
Withdrawn in favor of providing Kathy with editorial advice to
`minimize implicit requirements on debuggers' in the presentation of the
debugger in the standard.
EVAL-WHEN-NON-TOP-LEVEL - Option GENERALIZE-EVAL-NEW-KEYWORDS passed
EXIT-EXTENT -
Moon offered some amendments the effect of which were to allow you to throw again
to the same tag as you were already throwing to; specifically:
In the first paragraph of the MINIMAL proposal, delete "or is itself the
target exit" and change "events (c) and (d) at" to "event (c) occurs at".
After the first paragraph add a new paragraph "The event (d) occurs at the
end of the transfer of control."
The proposal was amended, and the amended option MINIMAL passed 11-5.
FUNCTION-COERCE-TIME -
Withdrawn; editors were instructed to be explicitly vague 16-1.
FUNCTION-NAME -
The net effect is that option LARGE passed with amendments to strike 7,8,9.
GENSYM-NAME-STICKINESS - Passed
HASH-TABLE-ACCESS -
Passed 17-0 with hand-written amendments by Pitman (and agreement that the
`obvious' write-o's would be corrected).
HASH-TABLE-SIZE - Deferred
IN-PACKAGE-FUNCTIONALITY -
The net effect is that NEW-MACRO passed with the name of SELECT-PACKAGE
changed to IN-PACKAGE.
IN-SYNTAX -
Version 2, which makes LOAD and *COMPILE-FILE* bind *READTABLE* (and
which does -not- introduce the IN-SYNTAX macro mentioned in version 1)
passed 12-0-3. This version was distributed by KMP in handwritten form.
LISP-PACKAGE-NAME -
The net effect is that this passed with amendment to rename package USER to
COMMON-LISP-USER with nickname CL-USER.
LISP-SYMBOL-REDEFINITION -
GZ wanted an amendment to strike item 8 from this list.
Sandra had some concern about the penultimate paragraph where she wanted a
prohibition on the ability to trace local functions (in implementations that
permit that). Moon thinks the proposal was amended to explicitly allow
tracing of such local function bindings.
We went round in circles about item 8. A straw poll to send this back for
more work failed 6-10, so we kept on.
A motion was made to terminate discussion. This passed by 2/3 vote.
Moon's notes say item 8 may need further refinement, as for instance by GLS's
amendment. The goal is to separate properties into the ones the user can
bash and the ones the user cannot bash.
Ultimately, I have written in my notes that we voted on
``proposal replaced by RPG, item 8 struck, w/ Sandra's prohibition
to trace local functions''
and that it passed 14-3.
Item 8 might be revisited at the next meeting.
LOAD-OBJECTS -
Moon proposed friendly amendment to use the name MAKE-LOAD-FORM-SAVING-SLOTS.
The amended proposal passed 18-0.
LOAD-TRUENAME - Deferred
LOCALLY-TOP-LEVEL - Passed
LOOP-AND-DISCREPANCY - Passed
MACRO-CACHING -
Tabled Tuesday. Not re-raised Thursday.
Might or might not come up at next meeting.
MACRO-ENVIRONMENT-EXTENT - option DYNAMIC passed 15-1.
MAKE-STRING-FILL-POINTER - Withdrawn
PACKAGE-FUNCTION-CONSISTENCY -
This was on the agenda but not discussed.
I expect it will come up at the next meeting.
PATHNAME-CANONICAL-TYPE - Deferred
PATHNAME-COMPONENT-CASE - Deferred
PATHNAME-COMPONENT-VALUE - Deferred
PATHNAME-LOGICAL - Deferred (but not seriously expected to come up again)
PATHNAME-PRINT-READ -
This was deferred from Tuesday to Thursday but then didn't come
around for discussion due to lack of time.
It might come up at the next meeting.
PATHNAME-SUBDIRECTORY-LIST - Deferred
PATHNAME-SYNTAX-ERROR-TIME - Deferred
PATHNAME-WILD - Deferred
PEEK-CHAR-READ-CHAR-ECHO -
Kim Barrett mentioned again that he wants to reopen this, but nothing was done.
PRETTY-PRINT-INTERFACE - Deferred
PRINT-CASE-PRINT-ESCAPE-INTERACTION -
This was deferred from Tuesday to Thursday but then didn't come up
for discussion. Being a clarification, I expect it to come up at the
next meeting.
PRINT-CIRCLE-SHARED -
This was deferred from Tuesday to Thursday but then didn't come up
for discussion. Since some people consider this almost a clarification,
this might come up at the next meeting.
PROCLAIM-LEXICAL - Failed
READ-CASE-SENSITIVITY - Deferred
READ-DELIMITED-LIST-EOF -
This issue was mentioned but was not on my list of possible topics.
No action was taken. It's probably a clarification and I guess it might
still come up later.
REAL-NUMBER-TYPE - Passed (the `union' of the two proposals)
REMF-DESTRUCTION-UNSPECIFIED - Passed
REQUIRE-PATHNAME-DEFAULTS -
Reconsidered but no change made. Previous vote stands.
SETF-MULTIPLE-STORE-VARIABLES -
This was on the agenda but never gotten to.
I think it might come up at the next meeting.
SYMBOL-MACROLET-SEMANTICS - Version 6 passed.
SYNTACTIC-ENVIRONMENT-ACCESS - Deferred
THE-AMBIGUITY -
This didn't come up. Being a clarification, I assume it might come up next meeting.
TIME-ZONE-NON-INTEGER
Moon proposed time zones be multiples of 1/3600 so that they were
even numbers of seconds. (Some people suspected this was a subtle
marketing ploy for Symbolics.) This amendment was accepted 11-0.
Pitman proposed that we limit time zone to the range [-24,24], inclusive.
The inclusive was to allow countries to disagree on which end was open,
since it was agreed that the correct value here is a largely political,
rather than technical issue. The amendment was accepted 8-5.
The full proposal with both amendments passed 18-0.
TYPE-OF-UNDERCONSTRAINED -
Some people had some concerns about a previous version of this that passed.
We wanted to reconsider this, but didn't have the right hardcopy.
No action was taken. This will probably come up next meeting.
UNDEFINED-VARIABLES-AND-FUNCTIONS - Deferred
WITH-COMPILATION-UNIT -
This passed 11-6 with an amendment to say it defers "warnings" rather than "actions"
and with an amendment to say it does not apply to the COMPILE function (only to
COMPILE-FILE).
∂09-Apr-89 0921 CL-Cleanup-mailer Issue COMPLEX-RATIONAL-RESULT, version 2
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 9 Apr 89 09:21:18 PDT
Return-Path: <gls@Think.COM>
Received: from brigit.think.com by Think.COM; Sun, 9 Apr 89 12:20:54 EDT
Received: by brigit.think.com; Sun, 9 Apr 89 01:37:19 EDT
Date: Sun, 9 Apr 89 01:37:19 EDT
From: gls@Think.COM
Message-Id: <8904090537.AA00468@brigit.think.com>
To: cl-cleanup@sail.stanford.edu
Cc: gls@Think.COM
Subject: Issue COMPLEX-RATIONAL-RESULT, version 2
This was a good thing for Moon to bring up, but I think a couple
of desirable details were left uncovered. Here is a new version
to consider in June.
Detail 1 is that a mathematically rational or complex rational
value might result from arguments that are a mixture of rational
and complex rational; or a complex rational value might result
from arguments that are rational only.
Detail 2 is that the version 1 proposal mentions (complex float)
where I believe the more specific (complex single-float) is appropriate.
Detail 3 is that in some cases the option of an ordinary float
result is desirable or required rather than a (complex single-float);
consider the ABS function, for example.
Detail 4 is that if the true mathematical result is not rational
or complex rational, I think we want to specify that the returned
value is single-float or (complex single-float).
----------------------------------------------------------------
Issue: COMPLEX-RATIONAL-RESULT
References: CLtL p.203
Category: CLARIFICATION
Edit history: Version 1, 20-Mar-89, by Moon
Version 2, 08-Apr-89, by Steele
Problem description:
Referring to irrational and transcendental functions, CLtL says:
When the arguments to a function in this section are all rational and
the true mathematical result is also (mathematically) rational, then
unless otherwise noted an implementation is free to return either an
accurate result of type rational or a single-precision floating-point
approximation. If the arguments are all rational but the result cannot
be expressed as a rational number, then a single-precision
floating-point approximation is always returned.
Referring to EXPT, CLtL says:
If the base-number is of type RATIONAL and the power-number is an
INTEGER, the calculation will be exact and the result will be of
type RATIONAL; otherwise a floating-point approximation may result.
What about arguments of type (complex rational)?
Proposal (COMPLEX-RATIONAL-RESULT:EXTEND):
Extend the paragraph quoted above as follows to cover the components
of complex numbers. If the arguments to a function are all of type
(OR RATIONAL (COMPLEX RATIONAL)) and the true mathematical result is
(mathematically) a complex number with rational real and imaginary
parts, then unless otherwise noted an implementation is free to return
either an accurate result of type (OR RATIONAL (COMPLEX RATIONAL)) or
a single-precision floating-point approximation of type SINGLE-FLOAT
(permissible only if the imaginary part of the true mathematical
result is zero) or \cd{(COMPLEX SINGLE-FLOAT). If the arguments are
all of type (OR RATIONAL (COMPLEX RATIONAL)) but the result cannot be
expressed as a rational or complex rational number, then the returned
value will be of type SINGLE-FLOAT (permissible only if the imaginary
part of the true mathematical result is zero) or (COMPLEX SINGLE-FLOAT).
For EXPT of a (COMPLEX RATIONAL) to an integer power, the
calculation must be exact and the result will be of type
(OR RATIONAL (COMPLEX RATIONAL)).
Examples:
(log #c(-16 16) #c(2 2)) => 3 or approximately #c(3.0 0.0)
or approximately 3.0 (unlikely)
(abs #c(3/5 4/5)) => 1 or approximately 1.0
(expt #c(2 2) 3) => #c(-16 16)
(expt #c(2 2) 4) => -64
Rationale:
This seems most consistent with the treatment of real numbers.
Current practice:
Symbolics Genera 7.4 returns a (complex float) for the first example
and returns the specified answers for the second and third examples.
Other implementations were not surveyed.
Cost to Implementors:
Only EXPT would have to change, since the type of the other results
is at the discretion of the implementation.
Cost to Users:
Probably none, but it is hard to predict.
Cost of non-adoption:
Slightly less self-consistent language.
Performance impact:
None of any significance.
Benefits/Esthetics:
More self-consistent language.
Discussion:
None.
∂09-Apr-89 2155 CL-Cleanup-mailer Issue: LISP-SYMBOL-REDEFINITION, v.6
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Apr 89 21:55:03 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 09 APR 89 21:55:03 PDT
Date: 9 Apr 89 21:54 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: LISP-SYMBOL-REDEFINITION, v.6
To: cl-cleanup@SAIL.Stanford.EDU
line-fold: NO
Message-ID: <890409-215503-3430@Xerox>
I've compared my notes against Mary's minutes, and they agree
that we struck 8 and added a phrase "and to trace that binding"
("Sandra's amendment".)
!
Status: Passed, Mar 89 X3J13, as amended
Forum: Cleanup
Issue: LISP-SYMBOL-REDEFINITION
References: Cleanup issue PACKAGE-CLUTTER
CLtL pp 67-69 Defining named functions
Category: CLARIFICATION
Edit history: Masinter, Version 1, 17-Sep-88 from (Kolb, 14-Aug-87)
Masinter, Version 2, 7-Oct-88
Masinter, Version 3, 7-Oct-88, fix typos
van Roggen, Version 4, 13-Oct-88, undefined, not unspecified
Masinter, Version 5, 22-Nov-88, add more cases
Masinter, Version 6, 9-Apr-89, make Mar 89 X3j13 amendments
Problem description:
Is it legal to redefine Common Lisp functions? There is no explicit
prohibition, and many implementations do allow redefinition of
functions in the Lisp package.
CLtL only says that special forms can not be redefined. But this doesn't
solve the general problem of redefining system functions.
Proposal LISP-SYMBOL-REDEFINITION:MAR89-X3J13
Except where explicitly allowed, the consequences are undefined if any
of the following actions are performed on symbols in the COMMON-LISP
package:
1. Binding or altering its value (lexically or dynamically)
2. Defining or binding it as a function
3. Defining or binding it as a macro
4. Defining it as a type specifier (defstruct, defclass, deftype)
5. Defining it as a structure (defstruct)
6. Defining it as a declaration
7. Using it as a symbol macro
8. Altering its print name (this may already be prohibited)
9. Altering its package
10. Tracing it
11. Declaring or proclaiming it special or lexical
12. Declaring or proclaiming its type or ftype
13. Removing it from the package COMMON-LISP
If such a symbol is not globally defined as a variable or a constant,
it is allowed to lexically bind it and declare the type of that binding.
If such a symbol is not defined as a function, macro, or special form,
it is allowed to (lexically) bind it as a function and to declare the
ftype of that binding and to trace that binding.
If such a symbol is not defined as a function, macro, or special form,
it is allowed to (lexically) bind it as a macro.
Examples:
The behavior of the construct:
(FLET ((OPEN (filename &key direction) (format t "Open called....")
(OPEN filename :direction direction)))
(with-open-file (x "frob" :direction ':output)
(format t "was Open called?")))
is undefined; for example, the macro expansion of with-open-file might refer
to the OPEN function and might not.
(DEFUN CAR (X) (CDR X))
might signal an error.
Rationale:
This proposal is the only simple resolution of the problem description that
we can imagine that is consistent with current implementation techniques.
Allowing arbitrary redefinition of symbols in the system would place
severe restrictions on implementations not to actually use those symbols in
macro expansions of other symbols, in function calls, etc. While some
looser restrictions might do for any particular Common Lisp implementation,
there seems to be no good way to distinguish between those symbols that are
redefinable and those that are not.
In general, programs can redefine functions safely by creating new symbols in
their own package, possibly shadowing the name.
Current practice:
Many Lisp environments have some mechanism for warning about redefinition of
Lisp symbols and preventing accidental redefinition while allowing it where
necessary (e.g., to patch the Lisp system itself, fix a bug, add an
optimization.)
Fewer check for lexical redefinition, since such redefinition is not as
dangerous. Certainly, there are some symbols that are never used in macro
expansions of the standard Common Lisp macros. However, implementations do
differ on the behavior of macro expansions.
Cost to Implementors:
This proposal clarifies the status quo -- that the consequences are undefined. It
allows and encourages implementors to check for such redefinition, but does not
require it.
Cost to Users:
This proposal clarifies that implementations are free to check for a condition
that they might not have before, and may clarify that some current user code is
non-portable.
Benefits:
This issue frequently arises. Adopting this proposal would clarify a frequent
source of question about Common Lisp.
Cost of non-adoption:
Continued questions.
Esthetics:
Disallowing all redefinition is the simplest way of disallowing the ones that
really are trouble.
Discussion:
At the March 89 X3j13 meeting, a proposed additional constraint
("Altering its property list") was removed. Presumably this means
that conformal programs are allowed to alter the property list of
symbols in the COMMON-LISP package.
∂09-Apr-89 2239 CL-Cleanup-mailer Re: Issue: PACKAGE-FUNCTION-CONSISTENCY
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Apr 89 22:39:02 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 09 APR 89 22:38:45 PDT
Date: 9 Apr 89 22:38 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PACKAGE-FUNCTION-CONSISTENCY
In-reply-to: KMP%STONY-BROOK.SCRC.Symbolics:COM:Xerox's message of 4 Apr 89
12:31 PDT
To: KMP@Symbolics.COM
cc: CL-Cleanup@SAIL.Stanford.edu
Message-ID: <890409-223845-3466@Xerox>
I believe the status is that David mailed a Version 4 which contained the
correct wording for what was passed at the Jan 89 X3J13. I don't think we
need to discuss it again. I had it on the agenda because I knew my Version
3 was incorrect or cloudy.
I'm marking it "Passed, as amended, Jan 89 X3j13".
∂09-Apr-89 2248 CL-Cleanup-mailer Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Apr 89 22:48:14 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 09 APR 89 22:48:13 PDT
Date: 9 Apr 89 22:47 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Wed, 23 Nov 88 18:55 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <890409-224813-3470@Xerox>
You said:
"I have some concerns about your alternate proposal but my mind is not
closed. I need more time to study this alternative and would like to
postpone dealing with this issue until after the letter ballot, instead
targeting a mailing in time for an in-person vote in January.
"
I still like my alternative proposal, which is just a smaller,
but useful, subset.
∂09-Apr-89 2315 CL-Cleanup-mailer Re: PRETTY-PRINT-INTERFACE, version 4
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Apr 89 23:15:32 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 09 APR 89 23:15:22 PDT
Date: 9 Apr 89 23:14 PDT
From: masinter.pa@Xerox.COM
Subject: Re: PRETTY-PRINT-INTERFACE, version 4
In-reply-to: dick@wheaties.ai.mit.edu's message of Wed, 22 Mar 89 13:54:34
EST
To: dick@wheaties.ai.mit.edu
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890409-231522-3487@Xerox>
As I relayed to you, what I recall is that there was some squawking about
adding new FORMAT directives. Maybe we should break it up for voting.
∂09-Apr-89 2332 CL-Cleanup-mailer Issue: READ-DELIMITED-LIST-EOF
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Apr 89 23:32:26 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 09 APR 89 23:32:26 PDT
Date: 9 Apr 89 23:31 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: READ-DELIMITED-LIST-EOF
To: KMP@symbolics.com
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890409-233226-3497@Xerox>
This is what I have filed under "READ-DELIMITED-LIST-EOF".
I think this could well be handled under ERROR-CHECKING-IN-IO-CHAPTERS or
some such.
----- Begin Forwarded Messages -----
Date: Mon, 28 Nov 88 17:17 EST
From: Barry Margolin <barmar@Think.COM>
Subject: EOF during READ-DELIMITED-LIST
To: cl-cleanup@sail.stanford.edu
According to CLtL p.378, "it is always an error to hit end-of-file
during the operation of READ-DELIMITED-LIST." This makes
READ-DELIMITED-LIST almost useless, because it means that some user
input to an application can cause undefined effects.
I think that this particular "is an error" was not intended this way.
READ-DELIMITED-LIST should be the function that the standard "(" macro
character uses, and the latter is defined to signal an error if an EOF
occurs before the matching delimiter is read. Also, the previous
sentence says that this is the reason that there is no EOF-ERROR-P
argument; the implication is that READ-DELIMITED-LIST has an implicit
EOF-ERROR-P argument that is always non-NIL.
Has this already been cleaned up?
barmar
----- Next Message -----
Date: 29 Nov 88 14:45 PST
From: masinter.pa
Subject: Re: EOF during READ-DELIMITED-LIST
In-reply-to: Barry Margolin <barmar@Think.COM>'s message of Mon, 28 Nov 88
17:17 EST
To: Barry Margolin <barmar@Think.COM>
cc: masinter
As far as I know, there is no cleanup issue regarding READ-DELIMITED-LIST.
I think you might be proposing to change an "is an error" in CLtL into a
"signals an error"; if so, you might consider specifying the class of error
signalled.
----- End Forwarded Messages -----
∂10-Apr-89 0006 CL-Cleanup-mailer Re: Issue: TYPE-OF-UNDERCONSTRAINED
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Apr 89 00:06:14 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 10 APR 89 00:05:53 PDT
Date: 10 Apr 89 00:05 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: TYPE-OF-UNDERCONSTRAINED
In-reply-to: KMP%STONY-BROOK.SCRC.Symbolics:COM:Xerox's message of 4 Apr 89
13:32 PDT
To: KMP@Symbolics.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890410-000553-3516@Xerox>
Actually, Mary's notes and my recollection is that there was a motion to
reconsider that was tabled. I'm not sure this is the same as "no action was
tabled", but I think it definitely will come up next meeting.
∂10-Apr-89 0028 CL-Cleanup-mailer Cleanup Issue status, 10-Apr-89
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Apr 89 00:28:23 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 APR 89 00:28:19 PDT
Date: 10 Apr 89 00:27 PDT
From: masinter.pa@Xerox.COM
Subject: Cleanup Issue status, 10-Apr-89
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Thu, 6 Apr 89 14:14 EDT
To: CL-Cleanup@SAIL.Stanford.EDU, chapman%aitg.dec@decwrl.dec.com
line-fold: NO
Message-ID: <890410-002819-3553@Xerox>
Well, I had a couple of discrepancies, that I already sent mail
about, with Kent's notes. I think Mary has good notes this time,
and I checked them fairly carefully against mine.
Here's my issue status. Except for time-zone-non-integer,
I think I have updated versions of all passed
issues stored on arisia.xerox.com under the
clcleanup/passed
directory. The clcleanup/pending directory is unreliable.
Codes:
+ passed
* pending; to be considered later meeting
- withdrawn
released = "Mailed to X3J13@Sail.stanford.edu"
+ ADJUST-ARRAY-DISPLACEMENT
Version 4, 23-Nov-87
Status: passed, 1988
+ ADJUST-ARRAY-FILL-POINTER
Version 1, 15-MAR-88
Status: passed, 1988
+-* ADJUST-ARRAY-NOT-ADJUSTABLE
Synopsis: ADJUST-ARRAY on array made with :ADJUSTABLE NIL: "an error"?
Version 4, 11-Jan-89, Released 12-Jan-89
Status: Accepted with amendments Jan 89 X3J13
Comments: amendment had wording problem.
Version 9, 17-Mar-89, released 21-mar-89
Comments: still problems
Status: withdrawn Mar 89 X3J13, intend to revisit Jun 89 X3J13
+ APPLYHOOK-ENVIRONMENT
Synopsis: remove (useless) env argument to applyhook
Version 2, 10-Jan-89, Released 10-Jan-89
Status: Passed Jan-89 X3J13
+ AREF-1D
synopsis: add ROW-MAJOR-AREF
Version 7, 14-NOV-87
Status: Passed, 1988?
+ ARGUMENTS-UNDERSPECIFIED
Synopsis: Clarify various ranges missing from CLtL
Version 4, 21-Sep-88, Released 4 Dec 88
Status: Passed Jan 89 X3J13
+ ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Synopsis: What do array element-type declarations mean?
Version 9, 31-Oct-88, Released 5 Dec 88
Status: Passed Jan 89 X3J13
+ ASSOC-RASSOC-IF-KEY
Version 4, 23-NOV-87
Status: Passed, 1988?
+ BREAK-ON-WARNINGS-OBSOLETE
Synopsis: deprecate *BREAK-ON-WARNINGS* because of *BREAK-ON-SIGNALS*
Version 1, 07-Mar-89, Released 15-Mar-89
Version 2, 8-Apr-89, (not mailed, on arisia)
Status: Passed, as amended, Mar 89 X3J13
+ CLOS-CONDITIONS
Version 4, 10-Mar-89, released 16-Mar-89
Comments: define metaclass of conditions? Not here.
Status: Passed, Mar 89 X3J13
+ CLOSE-CONSTRUCTED-STREAMS
Synopsis: What does it mean to CLOSE a constructed stream?
Version 2, 12-Jan-89, Released 12-Jan-89
Status: Proposal ARGUMENT-STREAM-ONLY passed Jan 89 X3J13
+ CLOSED-STREAM-OPERATIONS
Synopsis: What operations are legal on closed streams?
Version 5, 5-Dec-88, released 5-Dec-88
Status: amended at Jan 89 X3J13; amendment withdrawn Mar 89 X3J13;
version 5 stands
- COERCE-INCOMPLETE
Synopsis: Extend COERCE
Version 3, 7-Mar-89, Released 14-Mar-89
Status: motion died for lack of second; withdrawn
+ COLON-NUMBER
Synopsis: :123 is an error
Version 1, 22-OCT-87
Status: Passed, 1988
+ COMMON-TYPE
Version 1, 20-Mar-89, released 21-Mar-89
Status: passed, Mar 89 X3J13
+ COMPLEX-RATIONAL-RESULT
Version 1, 20-Mar-89, released 21-Mar-89
Status: passed, Mar 89 X3J13
+ COMPILER-WARNING-STREAM
Version 6, 5-JUN-87
Status: Passed, 1988
+ COMPLEX-ATAN-BRANCH-CUT
Synopsis: tweak upper branch cut in ATAN formula
Version 1, 13-Dec-88, Released 10-Jan-89
Status: Passed Jan 89 X3J13
* CONDITION-RESTARTS
Synopsis: can't know whether restart is associated with signalling
Version 1, 18-Jan-89, released 16-Mar-89
Comment: (proposed amendments)
Status: need new version
+ CONTAGION-ON-NUMERICAL-COMPARISONS
Version 1, 14-Sep-88, Released 6 Oct 88
Status: passed, Jan 89 X3J13
+ COPY-SYMBOL-COPY-PLIST
Version 1, 10-Jan-89, released 16-Mar-89
Status: passed, Mar 89 X3j13
+ COPY-SYMBOL-PRINT-NAME
Version 2, 15-Mar-89, released 16-Mar-89
Status: passed, Mar 89 X3j13
+ DATA-TYPES-HIERARCHY-UNDERSPECIFIED
Version 2, 4-SEP-88, released 4-Sep-88
Status: Passed, Aug 88 X3J13
+ DECLARATION-SCOPE
Version 4, 15-Nov-88, Released 9-Dec-88
Status: NO-HOISTING passed Jan 89 X3J13
+ DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Version 3, 13-Jan-89, released 3-Feb-89
Status: passed, Jan 89 X3J13
+ DECLARE-FUNCTION-AMBIGUITY
Version 4, 5-Dec-88, Released 5-Dec-88
Synopsis: (DECLARE (FUNCTION ...)) no longer synonym for FTYPE
Status: passed, Jan 89 X3J13
+ DECLARE-MACROS
Version 3, 5-FEB-88
Status: Passed, 1988?
+ DECLARE-TYPE-FREE
Version 10, 12-Jan-89
Status: proposal LEXICAL passed Jan 89 X3J13
+ DECODE-UNIVERSAL-TIME-DAYLIGHT
Version 2, 30-Sep-88, Released 6 Oct 88
Status: Passed, Jan 89 x3j13
+ DEFMACRO-LAMBDA-LIST
Version 3, 9-Apr-89, released 9-Apr-89
Status: Passed, as amended, Mar 89 X3J13
+ DEFPACKAGE
Version 7, 2-Nov-88, Released 5 Dec 88
Comment: clarify "at variance" in editorial work?
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
Version 3, 8-Jan-89, Released 11-Jan-89
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-DEFAULT-VALUE-EVALUATION
Version 1, 5/13/88
Status: Passed, 1988
+ DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
Version 3, 7 Dec 88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-REDEFINITION
Synopsis: what happens if you redefine a DEFSTRUCT?
Version 1, 7/26/88, released 8-Oct-88
Version 3, 6-Feb-89 (not released, on arisia)
Status: Passed (as amended) Jan 89 X3J13
+ DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
Version 5, 12-Jan-89
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER
Version 1, 5/13/88
Status: Passed, 1988
+ DEFVAR-DOCUMENTATION
Version 2, 23-NOV-87
Status: Passed, 1988
+ DEFVAR-INIT-TIME
Version 2, 29-MAR-87
Status: Passed, 1988
+ DEFVAR-INITIALIZATION
Version 4 5-JUN-87
Status: Passed, 1988
+ DESCRIBE-INTERACTIVE
Version 4, 15-Nov-88, Released 7-Dec-88
Synopsis: can DESCRIBE ask user a question?
Status: Proposal NO passed Jan 89 X3J13
+ DESCRIBE-UNDERSPECIFIED
Version 1, 10-Mar-89, Released 16-Mar-89
Synopsis: making DESCRIBE generic was wrong; fix
Version 2, 9-Apr-89 (not released, on arisia)
status: passed, as amended, Mar 89 X3J13
+* DESTRUCTURING-BIND
Version 2, 25-Jan-89, Released 16-Mar-89
Synopsis: add DESTRUCTURING-BIND macro
Version 3, Mar 89, (Circulated at Mar 89 X3J13)
Status: passed, Mar 89 X3J13
*** NO VERSION ON ARISIA ***
* DIRECTORY-DOES-TO-MUCH
Version 1
Status: not on agenda, didn't get to; withdraw?
+ DISASSEMBLE-SIDE-EFFECT
Version 3 1/21/88
Status: Passed, 1988
+ DO-SYMBOLS-DUPLICATES
Version 3 23-NOV-87
Status: Passed, 1988
+ DOTTED-MACRO-FORMS
Version 3, 15-Nov-88, Released 7-Dec-88
Status: passed, Jan 89 X3J13
+ DRIBBLE-TECHNIQUE
Version 2, 14-FEB-88
Status: Passed, 1988
+ DYNAMIC-EXTENT
Version 3, 11-Jan-89, released 16-Mar-89
Version 4, 5-Apr-89, as amended (not released to X3j13, on arisia)
Status: passed, as amended, Mar 89 X3J13
* DYNAMIC-EXTENT-FUNCTION
Comment: spin-off of DYNAMIC-EXTENT, to be considered Jun 89
+ EQUAL-STRUCTURE
Version 6, 11-Jan-89, Released 12-Jan-89
Version 7, 15-Mar-89 (not released to X3j13, on arisia)
Status: Passed Jan 89 X3J13 as amended.
- EQUALP-GENERIC
Version 1, 28-Feb-89
Synopsis: make EQUALP generic function
Status: withdrawn, Mar 89 X3J13
* ERROR-CHECKING-IN-NUMBERS-CHAPTER
Version 1, 6-Mar-89
Synopsis: define 'should signal', 'might signal' for number fns
Status: to be considered Jun 89
- ERROR-NOT-HANDLED
Version 1, 25-Sep-88, Released 6-Oct-88 and 14-Mar-89
Status: withdrawn; made editorial advice
+ EVAL-OTHER
8-JUN-88, Version 2
Status: Passed, 1988?
+ EXIT-EXTENT
Version 6, 8-Jan-89, distributed Jan89 X3J13, Rereleased 16-Mar-89
Version 7, 4-Apr-89, as amended (not released to X3j13, on arisia)
Status: Passed, Mar 89 X3j13, as amended
+ EXPT-RATIO
Version 3, 31-Oct-88, Released 7 Dec 88
Status: passed, Jan 89 X3J13
+ FIXNUM-NON-PORTABLE
Version 4, 7-Dec-88, Released 12-Dec-88
Version 6, 17-Mar-89, as amended
Status: Passed, Jan 89 X3J13, as amended
+ FLET-DECLARATIONS
Version 2, 2 FEB 88
Status: Passed, 1988
+ FLET-IMPLICIT-BLOCK
Version 6, 5-JUN-87
Status: Passed, 1988
+ FORMAT-ATSIGN-COLON
Version 4, 5-JUN-87
Status: Passed, 1988
+ FORMAT-COLON-UPARROW-SCOPE
Version 3, 5 FEB 88
Status: Passed, 1988
+ FORMAT-COMMA-INTERVAL
Version 2, 15-JUN-87
Status: Passed, 1988
+ FORMAT-E-EXPONENT-SIGN
Version 2, 2 Oct 88, Released 6 Oct 88
Status: Passed, Jan 89 X3J13
+ FORMAT-OP-C
11-JUN-87, Version 5
Status: Passed, 1988
- FORMAT-PLURALS
Synopsis: remove ~P, add ~:@[singular~;plural~]
Status: not submitted, will not be considered
+ FORMAT-PRETTY-PRINT
Version 7, 15 Dec 88, Released 7 Dec 88
Comments: passed, Jan 89 X3j13
+ FUNCTION-CALL-EVALUATION-ORDER
Version 1, 22-MAR-88
Status: Passed, 1988
- FUNCTION-COERCE-TIME
Synopsis: When does SYMBOL-FUNCTION happen in MAPCAR?
Version 2, 16-sep-88, Released 8-Oct-88
Re-released: 16-Mar-89
Status: withdrawn; request editor to rewrite as explicitly vague
+ FUNCTION-COMPOSITION
Synopsis: Add new functions
Version 5, 10-Feb-89 (not released to X3j13; on arisia)
Status: Passed (as amended) Jan 89 X3J13
maybe this was passed as amendment to TEST-NOT-IF-NOT instead
+ FUNCTION-DEFINITION
Version 3, 10-Feb-89 (not released to X3J13, on arisia)
Status: Passed (as amended) Jan 89 X3J13
+ FUNCTION-NAME
Comment: renaming of SETF-FUNCTION-VS-MACRO, SETF-PLACES
Version 1, 27-Jan-89, Released 16-Mar-89
Status: FUNCTION-NAME:LARGE with sections 7, 8, and 9 removed, passed
Mar 89 X3J13
+ FUNCTION-TYPE
Version 12, 4-SEP-88, released 4-sep-88
Status: Passed, June 1988 X3J13, as amended
+ FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
Synopsis: Change semantics of argument types in function declarations
Version 3, 7-Dec-88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13
+ FUNCTION-TYPE-KEY-NAME
Version 3, 13-FEB-88
Status: Passed, 1988
+ FUNCTION-TYPE-REST-LIST-ELEMENT
Version 5, 14-Nov-88, Released 8-Dec-88
Status: Passed, Jan 89 X3J13
+ GENSYM-NAME-STICKINESS
Synopsis: no side effects if optional arg supplied
Version 3, 20-Mar-89, Released 23-Mar-89
Status: passed, Mar 89 X3J13
+ GET-MACRO-CHARACTER-READTABLE
Version 3, 11-Feb-89 (not released; on arisia)
Status: Passed (as amended) Jan 89 X3J13
+ GET-SETF-METHOD-ENVIRONMENT
Version 5 13-JUL-87
Status: Passed, 1988
+ HASH-TABLE-ACCESS
Synopsis: Add new accessors for hash-table properties
Version 2, 13 Oct 88, released 16-Mar-89
Version 3, 5-Apr-89 (not released to X3j13; on arisia from KMP)
status: passed, as amended, Mar 89 X3J13
+ HASH-TABLE-PACKAGE-GENERATORS
Version 7, 8-Dec-88, Released 9-Dec-88
Comments: The test-package-iterator example has the values
from the generator in the wrong order.
Status: passed, Jan 89 X3J13
- HASH-TABLE-PRINTED-REPRESENTATION
Version 2, 8-Jun-88
Comments: Use #S(ARRAY ...), #S(HASH-TABLE...), #S(PATHNAME...)?
Status: didn't get to it; withdrawn
* HASH-TABLE-SIZE
Version 1, 20-Mar-89, released 21-Mar-89
Status: Postponed to Jun 89
+ HASH-TABLE-TESTS
Version 2, 8-Dec-88, Released 8 Dec 88
Status: passed Jan 89 X3J13
+ IEEE-ATAN-BRANCH-CUT
Version 2, 11-Jan-89, Released 11-Jan-89
Status: passed, Jan 89 X3J13
- IGNORE-VARIABLE
Synopsis: default (IGNORE IGNORE)
Version 1, 6-Feb-89
Status: didn't get to it by Mar 89; withdrawn
+ IMPORT-SETF-SYMBOL-PACKAGE
Version 5, MAY-87
Status: Passed, 1988?
+ IN-PACKAGE-FUNCTIONALITY
Version 8, 15-Mar-89, Released 15-Mar-89
Version 9, 9-Apr-89, as amended Mar89 X3J13, (not released, on Arisia)
Status: passed, as amended, Mar 89 X3J13
+ IN-SYNTAX
Version 3, 9-Apr-89 (not released, on Arisia)
Status: Version 2 (without cost/benefit analysis, but same proposal)
passed Mar 89 X3J13
+ KEYWORD-ARGUMENT-NAME-PACKAGE
Version 8, 8-NOV-87
Status: Passed, 1988?
+ LAST-N
12-MAR-88, Version 2
Status: Passed, 1988?
+ LCM-NO-ARGUMENTS
Version 1, 17 Oct 88, Released 8 Dec 88
Status: passed, Jan 89 X3J13
+ LISP-PACKAGE-NAME
Synopsis: change LISP to COMMON-LISP to avoid CLtL confusion
Version 1, 22 Dec 88, Released 11-Jan-89
Version 2, 9-Apr-89, as amended Mar 89 X3J13. Not released, on arisia
Status: passed, as amended, Mar 89 X3J13
+ LISP-SYMBOL-REDEFINITION
Version 5, 22-Nov-88, Released 8 Dec 88
Version 6, 9-Apr-89, as amended Mar 89 X3j13 (not released to X3j13, on arisia)
Status: passed, as amended, Mar 89 X3J13
+ LOAD-OBJECTS
Synopsis: Provide a way to allow defstruct/defclass objects in compiled files
Version 3, 9-Mar-89, released 16-Mar-89
Version 4, 4-Apr-89, (not released to X3J13, on arisia)
Status: passed, as amended, Mar 89 X3J13
* LOAD-TRUENAME
Synopsis: Make default pathname for LOAD inside LOAD same?
Version 1, 13-Mar-89, Released 16-Mar-89
Version 2 mailed, withdrawn. KMP has amendments
Status: postponed to Jun 89
+ LOCALLY-TOP-LEVEL
Version 2, 16-Mar-89, released 17-Mar-89
Status: passed, Mar 89 X3J13
+ LOOP-AND-DISCREPANCY
Version 1, 15-Mar-89, released 16-Mar-89
status: passed, Mar 89 X3J13
+ MACRO-FUNCTION-ENVIRONMENT
Version 2, 8-JUN-88
Status: Passed, 1988
- MACRO-SPECIAL-FORMS
Synopsis: macros => implementation-dependent special forms doesn't work
Status: didn't get to Mar 89; withdraw? ???
(LMM: I'm uneasy about withdrawning.)
+ MAKE-PACKAGE-USE-DEFAULT
Version 2, 8 Oct 88, Released 12-Dec-88
Version 3, 16-Mar-89
Status: Passed, Jan 89 X3J13 as amended
- MAKE-STRING-FILL-POINTER
Synopsis: extend MAKE-STRING to take a fill-pointer?
Version 1, 20-Oct-88, released 16-Mar-89
Status: withdrawn
+ MAPPING-DESTRUCTIVE-INTERACTION
Version 2, 09-Jun-88, Released 8 Oct 88
Synopsis: [don't] define interaction of DELETE on MAPCAR'd list.
Status: passed, Jan 89 X3J13
+ NTH-VALUE
Version 4, 8-Dec-88, Released 8 Dec 88
Comment: amended to clarify when index out of range
Version 5, 17-Mar-89 (not released; on arisia)
Status: passed, as amended, Jan 89 X3J13
+ PACKAGE-CLUTTER
Version 6, 12-Dec-88, Released 12-Dec-88
Comments: Accepted, with amendment
Version 7, 17-Mar-89 (not released; on arisia)
Status: Passed, Jan 89 X3J13, as amended
+ PACKAGE-DELETION
Version 5, 21 nov 88, Released 8 Dec 88
Status: passed, Jan 89 X3J13
+ PACKAGE-FUNCTION-CONSISTENCY
Synopsis: allow strings for package arg everywhere uniformly
Version 2, 12-Jan-89, Released 12-Jan-89
Version 4, 17-Mar-89, released 18-Mar-89
Status: passed, as amended, Jan 89 X3J13
* PATHNAME-CANONICAL-TYPE
Synopsis: allow canonical :SOURCE-LISP to MAKE-PATHNAME; add PATHNAME-CANONICAL-TYPE?
Version 1, 07-Jul-88
Status: postponed till Jun 89 X3J13
* PATHNAME-COMPONENT-CASE
Version 2, 22-Mar-89, released 22-Mar-89
Status: postponed till Jun 89 X3J13
* PATHNAME-COMPONENT-VALUE
Version 1, 20-Mar-89, released 21-Mar-89
Status: postponed till Jun 89 X3J13
* PATHNAME-EXTENSIONS
Version 1, 28-Dec-88
Status: ??? not discussed
* PATHNAME-LOGICAL
Synopsis: add logical pathnames (pathnames for an imaginary portable
file system, which get translated by site-dependent translations into
physical pathnames on an actual file system)
Status: no proposal yet
* PATHNAME-PRINT-READ
Synopsis: Print pathnames like #P"asdf"?
Version 1, 21-Oct-88, released 23-Mar-89
Status: postponed? Mar 89 to Thursday but not to Jun?
+ PATHNAME-STREAM
Version 6 14-NOV-87
Status: Passed, 1988
* PATHNAME-SUBDIRECTORY-LIST
Version 4, 22-Mar-89, released 22-mar-89 (Moon's version)
Status: Postponed to Jun 89 X3J13
+ PATHNAME-SYMBOL
Version 5 5-FEB-88
Status: Passed, 1988
* PATHNAME-SYNTAX-ERROR-TIME
Synopsis: when are errors in pathnames detected?
Version 1, 7-Jul-88, released 23-Mar-89
Comments: only want proposal PATHNAME-CREATION
Status: postponed to Jun 89 X3J13
+ PATHNAME-UNSPECIFIC-COMPONENT
Synopsis: More extensions to :UNSPECIFIC
Version 1, 29-Dec-88, Released 12-Jan-89
Version 2, 17-Mar-89 (not released, on arisia)
Status: Passed, Jan 89 X3j13, as amended
* PATHNAME-WILD
Version 2
Status: postponed to Jun 89
*+ PEEK-CHAR-READ-CHAR-ECHO
Version 3, 8-Oct-88, Released 8 Oct 88
Synopsis: PEEK-CHAR, READ-CHAR on streams made by MAKE-ECHO-STREAM
Status: Passed, Jan 89 X3J13
Kim Barrett wants to reopen
* PRETTY-PRINT-INTERFACE
Version 3, 15-Mar-89
Synopsis: standardize interface to prettyprinter
Status: postponed to Jun 89 X3J13
+ PRINC-CHARACTER
29-APR-87, Version 2
Status: Passed, 1988?
* PRINT-CASE-PRINT-ESCAPE-INTERACTION
Version 1, 26-Jan-89
Status: postponed tues -> thur; didn't get to. Revisit, probably
VERTICAL-BAR-RULE-NO-UPCASE
* PRINT-CIRCLE-SHARED
Synopsis: does *PRINT-CIRCLE* cause shared structure to print with #=?
Status: didn't get to; withdraw? revisit?
+ PRINT-CIRCLE-STRUCTURE
Version 3, 20 Sep 88, Released 8 Oct 88
Comments: Accepted, with amendment
Version 4, 17-Mar-89 (not released, on arisia)
Status: Passed, Jan 89 X3J13, as amended
- PROCLAIM-LEXICAL
Version 9, 8-Dec-88, Released 12-Dec-88
Synopsis: add LEXICAL proclaimation
Comments: lengthy mail; amendments at Jan meeting
Status: amended, then failed, Mar 89 X3J13
+ PUSH-EVALUATION-ORDER
Version 5, 25-NOV-87
Status: Passed, 1988
+ RANGE-OF-COUNT-KEYWORDS
Version 3, 9-Oct-88, Released 14-Oct-88
Status: passed, Jan 89 X3J13
+ RANGE-OF-START-AND-END-PARAMETERS
Version 1, 14-Sep-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
* READ-CASE-SENSITIVITY
Synopsis: Allow readtables to be case sensitive
Version 2, 23-Mar-89
Status: postponed to Jun 89; need one alternative
* READ-DELIMITED-LIST-EOF
Synopsis: eof in read deliminted list signals an error
Status: awaiting submission
+ REAL-NUMBER-TYPE
Synopsis: add REAL = (OR RATIONAL FLOAT) & range
Version 3, 13-Jan-89, released 16-Mar-89
Version 4, 5-Apr-89, as amended (not released, on arisia)
Status: passed, as amended, Mar 89 X3j13
+ REDUCE-ARGUMENT-EXTRACTION
Version 3 13-FEB-88
Status: Passed, 1988
+ REMF-DESTRUCTION-UNSPECIFIED
Synopsis: Specification of side-effect behavior in CL
Version 7, 5-Apr-89 (not released, as amended, on arisia)
Status: passed, as amended, Mar 89 X3J13
+ REQUIRE-PATHNAME-DEFAULTS
Version 6, 9 Dec 88, Released 09 Dec 88
Status: passed, Jan 89 X3j13
(Motion to retract failed Mar 89 X3J13)
+ REST-LIST-ALLOCATION
Version 3, 12-Dec-88, Released 12-Dec-88
Status: proposal MAY-SHARE passed, Jan 89 X3J13
+ RETURN-VALUES-UNSPECIFIED
Version 6, 9 Dec 88, Released 9-Dec-88
Status: passed, Jan 89 X3J13
+ ROOM-DEFAULT-ARGUMENT
Version 1, 12-Sep-88, Released 8 Oct 88
Status: passed, Jan 89 X3J13
* SETF-MULTIPLE-STORE-VARIABLES
Synopsis: Allow multiple "places" in SETF stores
Version 2, 22-Mar-89, released 22-Mar-89
Status: didn't get to Mar 89 X3J13.. withdraw?
+ SETF-SUB-METHODS
Version 5, 12-Feb-88, Released 8 Oct 88
Synopsis: careful definition of order inside (SETF (GETF ...) ...)
Status: passed, Jan 89 X3J13
+ SHADOW-ALREADY-PRESENT
Version 4 10-NOV-87
Status: Passed, 1988?
+ SHARPSIGN-PLUS-MINUS-PACKAGE
Version 3 14-NOV-87
Status: Passed, 1988?
+ SPECIAL-TYPE-SHADOWING
Synopsis: intersection of types when proclaimed special has local type
declaration
Version 1, 4-Nov-88, released 11-Jan-89
Status: passed, Jan 89 X3J13
+ STANDARD-INPUT-INITIAL-BINDING
Version 8, 8 Jul 88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
+ STEP-ENVIRONMENT
Version 3, 20-Jun-88, Released 7 Oct 88
Version 4, 17-Mar-89
status: Passed, Jan 89 X3J13, as amended
+ STREAM-ACCESS
Version 2, 30-Nov-88, Released 9 Dec 88
Status: ADD-TYPES-ACCESSORS passed, Jan 89 X3J13
* STREAM-DEFINITION-BY-USER
Version 1, 22-Mar-89, Released hardcopy Mar 89 X3J13
Comments: Cleanup forum? For 'future directions'?
+ SUBSEQ-OUT-OF-BOUNDS
29-MAR-88 Version 2
Status: Passed, 1988?
- SUBTYPEP-ENVIRONMENT
Version 1, 2-Jan-89
Status: missing writeup, didn't get to, withdraw
+ SUBTYPEP-TOO-VAGUE
Version 4, 7-Oct-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
+ SYMBOL-MACROLET-DECLARE
Version 2, 9-Dec-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13
+ SYMBOL-MACROLET-SEMANTICS
Status: Version 5, Passed, Jan 89 X3J13
Version 6, 14-Mar-89, released 16-Mar-89
Status: Version 6 (reconsidered), passed, Mar 89 X3J13
+ TAILP-NIL
Version 5, 9-Dec-88, Released 12-Dec-88
Synopsis: Operation of TAILP given NIL
Status: passed, Jan 89 X3J13
+ TEST-NOT-IF-NOT
Version 3, 1 Dec 88, Released 9 dec
Version 4, 18-Mar-89
Status: Need new version as amended.
* THE-AMBIGUITY
Version 2, 11-Jan-89, Released 11-Jan-89
Comments: typo, sense wrong
Status: didn't come up Mar 89 X3J13; withdraw?
+ TIME-ZONE-NON-INTEGER
Version 1, 13-Mar-89, Released 16-Mar-89
Status: passed with amendments; *** NEED VERSION AS AMENDED ****
* TYPE-OF-UNDERCONSTRAINED
Version 3, 12-Dec-88, Released 12 Dec 88
Comments: Accepted, with amendments
Version 5, 16-Mar-89
Comments: Moon's comments, only some responses. Fix
Status: ** NEED NEW VERSION ***
* UNDEFINED-VARIABLES-AND-FUNCTIONS
Synopsis: What happens on an undefined function call, unbound variable ref?
Version 1, 29-Nov-88, Released 11-Jan-89
Comments: offline discussion about SLOT-UNBOUND
Status: vote on 1?
+ UNREAD-CHAR-AFTER-PEEK-CHAR
Version 2, 2-Dec-88, Released 12-Dec-88
Status: passed, Jan 89 X3J13
+ VARIABLE-LIST-ASYMMETRY
Version 3, 08-Oct-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13
+ WITH-OUTPUT-TO-STRING-APPEND-STYLE
Version 5, 7-JUN-88
Status: Passed, 1988
* WITH-OPEN-FILE-DOES-NOT-EXIST
Version 1, 17-Mar-89
Status: didn't get to; withdraw?
∂10-Apr-89 1025 CL-Cleanup-mailer Cleanup Issue status, 10-Apr-89
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Apr 89 10:25:20 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 APR 89 09:56:10 PDT
Date: 10 Apr 89 09:52 PDT
From: masinter.pa@Xerox.COM
Subject: Cleanup Issue status, 10-Apr-89
To: cl-cleanup@Sail.stanford.edu
Message-ID: <890410-095610-4389@Xerox>
Here's my revised issue status.
I think I have updated versions of all passed
issues stored on arisia.xerox.com under the
clcleanup/passed
directory. The clcleanup/pending directory is unreliable.
Do you think we need to mail the 'unreleased' versions to
X3J13?
!
Codes:
+ passed
* pending; to be considered later meeting
- withdrawn
released = "Mailed to X3J13@Sail.stanford.edu"
+ ADJUST-ARRAY-DISPLACEMENT
Version 4, 23-Nov-87
Status: passed, 1988
+ ADJUST-ARRAY-FILL-POINTER
Version 1, 15-MAR-88
Status: passed, 1988
+-* ADJUST-ARRAY-NOT-ADJUSTABLE
Synopsis: ADJUST-ARRAY on array made with :ADJUSTABLE NIL: "an error"?
Version 4, 11-Jan-89, Released 12-Jan-89
Status: Accepted with amendments Jan 89 X3J13
Comments: amendment had wording problem.
Version 9, 17-Mar-89, released 21-mar-89
Comments: still problems
Status: withdrawn Mar 89 X3J13, intend to revisit Jun 89 X3J13
+ APPLYHOOK-ENVIRONMENT
Synopsis: remove (useless) env argument to applyhook
Version 2, 10-Jan-89, Released 10-Jan-89
Status: Passed Jan-89 X3J13
+ AREF-1D
synopsis: add ROW-MAJOR-AREF
Version 7, 14-NOV-87
Status: Passed, 1988
+ ARGUMENTS-UNDERSPECIFIED
Synopsis: Clarify various ranges missing from CLtL
Version 4, 21-Sep-88, Released 4 Dec 88
Status: Passed Jan 89 X3J13
+ ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Synopsis: What do array element-type declarations mean?
Version 9, 31-Oct-88, Released 5 Dec 88
Status: Passed Jan 89 X3J13
+ ASSOC-RASSOC-IF-KEY
Version 4, 23-NOV-87
Status: Passed, 1988
+ BREAK-ON-WARNINGS-OBSOLETE
Synopsis: deprecate *BREAK-ON-WARNINGS* because of *BREAK-ON-SIGNALS*
Version 1, 07-Mar-89, Released 15-Mar-89
Version 2, 8-Apr-89, (not mailed, on arisia)
Status: Passed, as amended, Mar 89 X3J13
+ CLOS-CONDITIONS
Version 4, 10-Mar-89, released 16-Mar-89
Comments: define metaclass of conditions? Not here.
Status: Passed, Mar 89 X3J13
+ CLOSE-CONSTRUCTED-STREAMS
Synopsis: What does it mean to CLOSE a constructed stream?
Version 2, 12-Jan-89, Released 12-Jan-89
Status: Proposal ARGUMENT-STREAM-ONLY passed Jan 89 X3J13
+ CLOSED-STREAM-OPERATIONS
Synopsis: What operations are legal on closed streams?
Version 5, 5-Dec-88, released 5-Dec-88
Status: amended at Jan 89 X3J13; amendment withdrawn Mar 89 X3J13;
version 5 stands
- COERCE-INCOMPLETE
Synopsis: Extend COERCE
Version 3, 7-Mar-89, Released 14-Mar-89
Status: motion died for lack of second; withdrawn
+ COLON-NUMBER
Synopsis: :123 is an error
Version 1, 22-OCT-87
Status: Passed, 1988
+ COMMON-TYPE
Version 1, 20-Mar-89, released 21-Mar-89
Status: passed, Mar 89 X3J13
+ COMPLEX-RATIONAL-RESULT
Version 1, 20-Mar-89, released 21-Mar-89
Status: passed, Mar 89 X3J13
+ COMPILER-WARNING-STREAM
Version 6, 5-JUN-87
Status: Passed, 1988
+ COMPLEX-ATAN-BRANCH-CUT
Synopsis: tweak upper branch cut in ATAN formula
Version 1, 13-Dec-88, Released 10-Jan-89
Status: Passed Jan 89 X3J13
* CONDITION-RESTARTS
Synopsis: can't know whether restart is associated with signalling
Version 1, 18-Jan-89, released 16-Mar-89
Comment: (proposed amendments)
Status: need new version
+ CONTAGION-ON-NUMERICAL-COMPARISONS
Version 1, 14-Sep-88, Released 6 Oct 88
Status: passed, Jan 89 X3J13
+ COPY-SYMBOL-COPY-PLIST
Version 1, 10-Jan-89, released 16-Mar-89
Status: passed, Mar 89 X3j13
+ COPY-SYMBOL-PRINT-NAME
Version 2, 15-Mar-89, released 16-Mar-89
Status: passed, Mar 89 X3j13
+ DATA-TYPES-HIERARCHY-UNDERSPECIFIED
Version 2, 4-SEP-88, released 4-Sep-88
Status: Passed, Aug 88 X3J13
+ DECLARATION-SCOPE
Version 4, 15-Nov-88, Released 9-Dec-88
Status: NO-HOISTING passed Jan 89 X3J13
+ DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Version 3, 13-Jan-89, released 3-Feb-89
Status: passed, Jan 89 X3J13
+ DECLARE-FUNCTION-AMBIGUITY
Version 4, 5-Dec-88, Released 5-Dec-88
Synopsis: (DECLARE (FUNCTION ...)) no longer synonym for FTYPE
Status: passed, Jan 89 X3J13
+ DECLARE-MACROS
Version 3, 5-FEB-88
Status: Passed, 1988?
+ DECLARE-TYPE-FREE
Version 10, 12-Jan-89
Status: proposal LEXICAL passed Jan 89 X3J13
+ DECODE-UNIVERSAL-TIME-DAYLIGHT
Version 2, 30-Sep-88, Released 6 Oct 88
Status: Passed, Jan 89 x3j13
+ DEFMACRO-LAMBDA-LIST
Version 3, 9-Apr-89, released 9-Apr-89 (as amended)
Version 4, 10-Apr-89 (left out an amendment; not released)
Status: Passed, as amended, Mar 89 X3J13
+ DEFPACKAGE
Version 7, 2-Nov-88, Released 5 Dec 88
Comment: clarify "at variance" in editorial work?
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
Version 3, 8-Jan-89, Released 11-Jan-89
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-DEFAULT-VALUE-EVALUATION
Version 1, 5/13/88
Status: Passed, 1988
+ DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
Version 3, 7 Dec 88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-REDEFINITION
Synopsis: what happens if you redefine a DEFSTRUCT?
Version 1, 7/26/88, released 8-Oct-88
Version 3, 6-Feb-89 (not released, on arisia)
Status: Passed (as amended) Jan 89 X3J13
+ DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
Version 5, 12-Jan-89
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER
Version 1, 5/13/88
Status: Passed, 1988
+ DEFVAR-DOCUMENTATION
Version 2, 23-NOV-87
Status: Passed, 1988
+ DEFVAR-INIT-TIME
Version 2, 29-MAR-87
Status: Passed, 1988
+ DEFVAR-INITIALIZATION
Version 4 5-JUN-87
Status: Passed, 1988
+ DESCRIBE-INTERACTIVE
Version 4, 15-Nov-88, Released 7-Dec-88
Synopsis: can DESCRIBE ask user a question?
Status: Proposal NO passed Jan 89 X3J13
+ DESCRIBE-UNDERSPECIFIED
Version 1, 10-Mar-89, Released 16-Mar-89
Synopsis: making DESCRIBE generic was wrong; fix
Version 2, 9-Apr-89 (not released, on arisia)
status: passed, as amended, Mar 89 X3J13
+ DESTRUCTURING-BIND
Version 2, 25-Jan-89, Released 16-Mar-89
Synopsis: add DESTRUCTURING-BIND macro
Version 3, Mar 89, (circulated at Mar 89 X3J13, not released, on arisia)
Status: passed, Mar 89 X3J13
* DIRECTORY-DOES-TO-MUCH
Version 1
Status: not on agenda, didn't get to; withdraw?
+ DISASSEMBLE-SIDE-EFFECT
Version 3 1/21/88
Status: Passed, 1988
+ DO-SYMBOLS-DUPLICATES
Version 3 23-NOV-87
Status: Passed, 1988
+ DOTTED-MACRO-FORMS
Version 3, 15-Nov-88, Released 7-Dec-88
Status: passed, Jan 89 X3J13
+ DRIBBLE-TECHNIQUE
Version 2, 14-FEB-88
Status: Passed, 1988
+ DYNAMIC-EXTENT
Version 3, 11-Jan-89, released 16-Mar-89
Version 4, 5-Apr-89, as amended (not released to X3j13, on arisia)
Status: passed, as amended, Mar 89 X3J13
* DYNAMIC-EXTENT-FUNCTION
Comment: spin-off of DYNAMIC-EXTENT, to be considered Jun 89
Version 1, 4-Apr-89
- ENVIRONMENT-ENQUIRY
Synopsis: "The environment inquiry functions (pp447-448) don't return a
value in consistent format across implementations. This makes
them virtually useless. I would like to constrain the values
enough so that implementors knew what to provide as return
values, and provide some examples of intended uses."
Status: didn't get to; withdrawn
+ EQUAL-STRUCTURE
Version 6, 11-Jan-89, Released 12-Jan-89
Version 7, 15-Mar-89 (not released to X3j13, on arisia)
Status: Passed Jan 89 X3J13 as amended.
- EQUALP-GENERIC
Version 1, 28-Feb-89
Synopsis: make EQUALP generic function
Status: withdrawn, Mar 89 X3J13
* ERROR-CHECKING-IN-NUMBERS-CHAPTER
Version 1, 6-Mar-89
Synopsis: define 'should signal', 'might signal' for number fns
Status: to be considered Jun 89
- ERROR-NOT-HANDLED
Version 1, 25-Sep-88, Released 6-Oct-88 and 14-Mar-89
Status: withdrawn; made editorial advice
+ EVAL-OTHER
8-JUN-88, Version 2
Status: Passed, 1988?
+ EXIT-EXTENT
Version 6, 8-Jan-89, distributed Jan89 X3J13, Rereleased 16-Mar-89
Version 7, 4-Apr-89, as amended (not released to X3j13, on arisia)
Status: Passed, Mar 89 X3j13, as amended
+ EXPT-RATIO
Version 3, 31-Oct-88, Released 7 Dec 88
Status: passed, Jan 89 X3J13
+ FIXNUM-NON-PORTABLE
Version 4, 7-Dec-88, Released 12-Dec-88
Version 6, 17-Mar-89, as amended
Status: Passed, Jan 89 X3J13, as amended
+ FLET-DECLARATIONS
Version 2, 2 FEB 88
Status: Passed, 1988
+ FLET-IMPLICIT-BLOCK
Version 6, 5-JUN-87
Status: Passed, 1988
+ FORMAT-ATSIGN-COLON
Version 4, 5-JUN-87
Status: Passed, 1988
+ FORMAT-COLON-UPARROW-SCOPE
Version 3, 5 FEB 88
Status: Passed, 1988
+ FORMAT-COMMA-INTERVAL
Version 2, 15-JUN-87
Status: Passed, 1988
+ FORMAT-E-EXPONENT-SIGN
Version 2, 2 Oct 88, Released 6 Oct 88
Status: Passed, Jan 89 X3J13
+ FORMAT-OP-C
11-JUN-87, Version 5
Status: Passed, 1988
- FORMAT-PLURALS
Synopsis: remove ~P, add ~:@[singular~;plural~]
Status: not submitted, will not be considered
+ FORMAT-PRETTY-PRINT
Version 7, 15 Dec 88, Released 7 Dec 88
Comments: passed, Jan 89 X3j13
+ FUNCTION-CALL-EVALUATION-ORDER
Version 1, 22-MAR-88
Status: Passed, 1988
- FUNCTION-COERCE-TIME
Synopsis: When does SYMBOL-FUNCTION happen in MAPCAR?
Version 2, 16-sep-88, Released 8-Oct-88
Re-released: 16-Mar-89
Status: withdrawn; request editor to rewrite as explicitly vague
+ FUNCTION-COMPOSITION
Synopsis: Add new functions
Version 5, 10-Feb-89 (not released to X3j13; on arisia)
Status: Passed (as amended) Jan 89 X3J13
maybe this was passed as amendment to TEST-NOT-IF-NOT instead
+ FUNCTION-DEFINITION
Version 3, 10-Feb-89 (not released to X3J13, on arisia)
Status: Passed (as amended) Jan 89 X3J13
+ FUNCTION-NAME
Comment: renaming of SETF-FUNCTION-VS-MACRO, SETF-PLACES
Version 1, 27-Jan-89, Released 16-Mar-89
Status: FUNCTION-NAME:LARGE with sections 7, 8, and 9 removed, passed
Mar 89 X3J13
+ FUNCTION-TYPE
Version 12, 4-SEP-88, released 4-sep-88
Status: Passed, June 1988 X3J13, as amended
+ FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
Synopsis: Change semantics of argument types in function declarations
Version 3, 7-Dec-88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13
+ FUNCTION-TYPE-KEY-NAME
Version 3, 13-FEB-88
Status: Passed, 1988
+ FUNCTION-TYPE-REST-LIST-ELEMENT
Version 5, 14-Nov-88, Released 8-Dec-88
Status: Passed, Jan 89 X3J13
+ GENSYM-NAME-STICKINESS
Synopsis: no side effects if optional arg supplied
Version 3, 20-Mar-89, Released 23-Mar-89
Status: passed, Mar 89 X3J13
+ GET-MACRO-CHARACTER-READTABLE
Version 3, 11-Feb-89 (not released; on arisia)
Status: Passed (as amended) Jan 89 X3J13
+ GET-SETF-METHOD-ENVIRONMENT
Version 5 13-JUL-87
Status: Passed, 1988
+ HASH-TABLE-ACCESS
Synopsis: Add new accessors for hash-table properties
Version 2, 13 Oct 88, released 16-Mar-89
Version 3, 5-Apr-89 (not released to X3j13; on arisia from KMP)
status: passed, as amended, Mar 89 X3J13
+ HASH-TABLE-PACKAGE-GENERATORS
Version 7, 8-Dec-88, Released 9-Dec-88
Comments: The test-package-iterator example has the values
from the generator in the wrong order.
Status: passed, Jan 89 X3J13
- HASH-TABLE-PRINTED-REPRESENTATION
Version 2, 8-Jun-88
Comments: Use #S(ARRAY ...), #S(HASH-TABLE...), #S(PATHNAME...)?
Status: didn't get to it; withdrawn
* HASH-TABLE-SIZE
Version 1, 20-Mar-89, released 21-Mar-89
Status: Postponed to Jun 89
+ HASH-TABLE-TESTS
Version 2, 8-Dec-88, Released 8 Dec 88
Status: passed Jan 89 X3J13
+ IEEE-ATAN-BRANCH-CUT
Version 2, 11-Jan-89, Released 11-Jan-89
Status: passed, Jan 89 X3J13
- IGNORE-VARIABLE
Synopsis: default (IGNORE IGNORE)
Version 1, 6-Feb-89
Status: didn't get to it by Mar 89; withdrawn
+ IMPORT-SETF-SYMBOL-PACKAGE
Version 5, MAY-87
Status: Passed, 1988?
+ IN-PACKAGE-FUNCTIONALITY
Version 8, 15-Mar-89, Released 15-Mar-89
Version 9, 9-Apr-89, as amended Mar89 X3J13, (not released, on Arisia)
Status: passed, as amended, Mar 89 X3J13
+ IN-SYNTAX
Version 3, 9-Apr-89 (not released, on Arisia)
Status: Version 2 (without cost/benefit analysis, but same proposal)
passed Mar 89 X3J13
+ KEYWORD-ARGUMENT-NAME-PACKAGE
Version 8, 8-NOV-87
Status: Passed, 1988?
+ LAST-N
12-MAR-88, Version 2
Status: Passed, 1988?
+ LCM-NO-ARGUMENTS
Version 1, 17 Oct 88, Released 8 Dec 88
Status: passed, Jan 89 X3J13
+ LISP-PACKAGE-NAME
Synopsis: change LISP to COMMON-LISP to avoid CLtL confusion
Version 1, 22 Dec 88, Released 11-Jan-89
Version 2, 9-Apr-89, as amended Mar 89 X3J13. Not released, on arisia
Status: passed, as amended, Mar 89 X3J13
+ LISP-SYMBOL-REDEFINITION
Version 5, 22-Nov-88, Released 8 Dec 88
Version 6, 9-Apr-89, as amended Mar 89 X3j13 (not released to X3j13, on arisia)
Status: passed, as amended, Mar 89 X3J13
+ LOAD-OBJECTS
Synopsis: Provide a way to allow defstruct/defclass objects in compiled files
Version 3, 9-Mar-89, released 16-Mar-89
Version 4, 4-Apr-89, (not released to X3J13, on arisia)
Status: passed, as amended, Mar 89 X3J13
* LOAD-TRUENAME
Synopsis: Make default pathname for LOAD inside LOAD same?
Version 1, 13-Mar-89, Released 16-Mar-89
Version 2 mailed, withdrawn. KMP has amendments
Status: postponed to Jun 89
+ LOCALLY-TOP-LEVEL
Version 2, 16-Mar-89, released 17-Mar-89
Status: passed, Mar 89 X3J13
+ LOOP-AND-DISCREPANCY
Version 1, 15-Mar-89, released 16-Mar-89
status: passed, Mar 89 X3J13
+ MACRO-FUNCTION-ENVIRONMENT
Version 2, 8-JUN-88
Status: Passed, 1988
- MACRO-SPECIAL-FORMS
Synopsis: macros => implementation-dependent special forms doesn't work
Status: didn't get to Mar 89; withdraw? ???
(LMM: I'm uneasy about withdrawning.)
+ MAKE-PACKAGE-USE-DEFAULT
Version 2, 8 Oct 88, Released 12-Dec-88
Version 3, 16-Mar-89
Status: Passed, Jan 89 X3J13 as amended
- MAKE-STRING-FILL-POINTER
Synopsis: extend MAKE-STRING to take a fill-pointer?
Version 1, 20-Oct-88, released 16-Mar-89
Status: withdrawn
+ MAPPING-DESTRUCTIVE-INTERACTION
Version 2, 09-Jun-88, Released 8 Oct 88
Synopsis: [don't] define interaction of DELETE on MAPCAR'd list.
Status: passed, Jan 89 X3J13
+ NTH-VALUE
Version 4, 8-Dec-88, Released 8 Dec 88
Comment: amended to clarify when index out of range
Version 5, 17-Mar-89 (not released; on arisia)
Status: passed, as amended, Jan 89 X3J13
+ PACKAGE-CLUTTER
Version 6, 12-Dec-88, Released 12-Dec-88
Comments: Accepted, with amendment
Version 7, 17-Mar-89 (not released; on arisia)
Status: Passed, Jan 89 X3J13, as amended
+ PACKAGE-DELETION
Version 5, 21 nov 88, Released 8 Dec 88
Status: passed, Jan 89 X3J13
+ PACKAGE-FUNCTION-CONSISTENCY
Synopsis: allow strings for package arg everywhere uniformly
Version 2, 12-Jan-89, Released 12-Jan-89
Version 4, 17-Mar-89, released 18-Mar-89
Status: passed, as amended, Jan 89 X3J13
* PATHNAME-CANONICAL-TYPE
Synopsis: allow canonical :SOURCE-LISP to MAKE-PATHNAME; add PATHNAME-CANONICAL-TYPE?
Version 1, 07-Jul-88
Status: postponed till Jun 89 X3J13
* PATHNAME-COMPONENT-CASE
Version 2, 22-Mar-89, released 22-Mar-89
Status: postponed till Jun 89 X3J13
* PATHNAME-COMPONENT-VALUE
Version 1, 20-Mar-89, released 21-Mar-89
Status: postponed till Jun 89 X3J13
* PATHNAME-EXTENSIONS
Version 1, 28-Dec-88
Status: ??? not discussed
* PATHNAME-LOGICAL
Synopsis: add logical pathnames (pathnames for an imaginary portable
file system, which get translated by site-dependent translations into
physical pathnames on an actual file system)
Status: no proposal yet
* PATHNAME-PRINT-READ
Synopsis: Print pathnames like #P"asdf"?
Version 1, 21-Oct-88, released 23-Mar-89
Status: postponed? Mar 89 to Thursday but not to Jun?
+ PATHNAME-STREAM
Version 6 14-NOV-87
Status: Passed, 1988
* PATHNAME-SUBDIRECTORY-LIST
Version 4, 22-Mar-89, released 22-mar-89 (Moon's version)
Status: Postponed to Jun 89 X3J13
+ PATHNAME-SYMBOL
Version 5 5-FEB-88
Status: Passed, 1988
* PATHNAME-SYNTAX-ERROR-TIME
Synopsis: when are errors in pathnames detected?
Version 1, 7-Jul-88, released 23-Mar-89
Comments: only want proposal PATHNAME-CREATION
Status: postponed to Jun 89 X3J13
+ PATHNAME-UNSPECIFIC-COMPONENT
Synopsis: More extensions to :UNSPECIFIC
Version 1, 29-Dec-88, Released 12-Jan-89
Version 2, 17-Mar-89 (not released, on arisia)
Status: Passed, Jan 89 X3j13, as amended
* PATHNAME-WILD
Version 2
Status: postponed to Jun 89
*+ PEEK-CHAR-READ-CHAR-ECHO
Version 3, 8-Oct-88, Released 8 Oct 88
Synopsis: PEEK-CHAR, READ-CHAR on streams made by MAKE-ECHO-STREAM
Status: Passed, Jan 89 X3J13
Kim Barrett wants to reopen
* PRETTY-PRINT-INTERFACE
Version 3, 15-Mar-89
Synopsis: standardize interface to prettyprinter
Status: postponed to Jun 89 X3J13
+ PRINC-CHARACTER
29-APR-87, Version 2
Status: Passed, 1988?
* PRINT-CASE-PRINT-ESCAPE-INTERACTION
Version 1, 26-Jan-89
Status: postponed tues -> thur; didn't get to. Revisit, probably
VERTICAL-BAR-RULE-NO-UPCASE
* PRINT-CIRCLE-SHARED
Synopsis: does *PRINT-CIRCLE* cause shared structure to print with #=?
Status: didn't get to; withdraw? revisit?
+ PRINT-CIRCLE-STRUCTURE
Version 3, 20 Sep 88, Released 8 Oct 88
Comments: Accepted, with amendment
Version 4, 17-Mar-89 (not released, on arisia)
Status: Passed, Jan 89 X3J13, as amended
- PROCLAIM-LEXICAL
Version 9, 8-Dec-88, Released 12-Dec-88
Synopsis: add LEXICAL proclaimation
Comments: lengthy mail; amendments at Jan meeting
Status: amended, then failed, Mar 89 X3J13
+ PUSH-EVALUATION-ORDER
Version 5, 25-NOV-87
Status: Passed, 1988
+ RANGE-OF-COUNT-KEYWORDS
Version 3, 9-Oct-88, Released 14-Oct-88
Status: passed, Jan 89 X3J13
+ RANGE-OF-START-AND-END-PARAMETERS
Version 1, 14-Sep-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
* READ-CASE-SENSITIVITY
Synopsis: Allow readtables to be case sensitive
Version 2, 23-Mar-89
Status: postponed to Jun 89; need one alternative
* READ-DELIMITED-LIST-EOF
Synopsis: eof in read deliminted list signals an error
Status: awaiting submission
+ REAL-NUMBER-TYPE
Synopsis: add REAL = (OR RATIONAL FLOAT) & range
Version 3, 13-Jan-89, released 16-Mar-89
Version 4, 5-Apr-89, as amended (not released, on arisia)
Status: passed, as amended, Mar 89 X3j13
+ REDUCE-ARGUMENT-EXTRACTION
Version 3 13-FEB-88
Status: Passed, 1988
+ REMF-DESTRUCTION-UNSPECIFIED
Synopsis: Specification of side-effect behavior in CL
Version 7, 5-Apr-89 (not released, as amended, on arisia)
Status: passed, as amended, Mar 89 X3J13
+ REQUIRE-PATHNAME-DEFAULTS
Version 6, 9 Dec 88, Released 09 Dec 88
Status: passed, Jan 89 X3j13
(Motion to retract failed Mar 89 X3J13)
+ REST-LIST-ALLOCATION
Version 3, 12-Dec-88, Released 12-Dec-88
Status: proposal MAY-SHARE passed, Jan 89 X3J13
+ RETURN-VALUES-UNSPECIFIED
Version 6, 9 Dec 88, Released 9-Dec-88
Status: passed, Jan 89 X3J13
+ ROOM-DEFAULT-ARGUMENT
Version 1, 12-Sep-88, Released 8 Oct 88
Status: passed, Jan 89 X3J13
* SETF-MULTIPLE-STORE-VARIABLES
Synopsis: Allow multiple "places" in SETF stores
Version 2, 22-Mar-89, released 22-Mar-89
Status: didn't get to Mar 89 X3J13.. withdraw?
+ SETF-SUB-METHODS
Version 5, 12-Feb-88, Released 8 Oct 88
Synopsis: careful definition of order inside (SETF (GETF ...) ...)
Status: passed, Jan 89 X3J13
+ SHADOW-ALREADY-PRESENT
Version 4 10-NOV-87
Status: Passed, 1988?
+ SHARPSIGN-PLUS-MINUS-PACKAGE
Version 3 14-NOV-87
Status: Passed, 1988?
+ SPECIAL-TYPE-SHADOWING
Synopsis: intersection of types when proclaimed special has local type
declaration
Version 1, 4-Nov-88, released 11-Jan-89
Status: passed, Jan 89 X3J13
+ STANDARD-INPUT-INITIAL-BINDING
Version 8, 8 Jul 88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
+ STEP-ENVIRONMENT
Version 3, 20-Jun-88, Released 7 Oct 88
Version 4, 17-Mar-89
status: Passed, Jan 89 X3J13, as amended
+ STREAM-ACCESS
Version 2, 30-Nov-88, Released 9 Dec 88
Status: ADD-TYPES-ACCESSORS passed, Jan 89 X3J13
* STREAM-DEFINITION-BY-USER
Version 1, 22-Mar-89, Released hardcopy Mar 89 X3J13
Comments: Cleanup forum? For 'future directions'?
+ SUBSEQ-OUT-OF-BOUNDS
29-MAR-88 Version 2
Status: Passed, 1988?
- SUBTYPEP-ENVIRONMENT
Version 1, 2-Jan-89
Status: missing writeup, didn't get to, withdraw
+ SUBTYPEP-TOO-VAGUE
Version 4, 7-Oct-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
+ SYMBOL-MACROLET-DECLARE
Version 2, 9-Dec-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13
+ SYMBOL-MACROLET-SEMANTICS
Status: Version 5, Passed, Jan 89 X3J13
Version 6, 14-Mar-89, released 16-Mar-89
Status: Version 6 (reconsidered), passed, Mar 89 X3J13
- TAIL-RECURSION-OPTIMIZATION
Version 2, Oct 88?
Status: dropped somehow?
+ TAILP-NIL
Version 5, 9-Dec-88, Released 12-Dec-88
Synopsis: Operation of TAILP given NIL
Status: passed, Jan 89 X3J13
+ TEST-NOT-IF-NOT
Version 3, 1 Dec 88, Released 9 dec
Version 4, 18-Mar-89
Status: Need new version as amended.
* THE-AMBIGUITY
Version 2, 11-Jan-89, Released 11-Jan-89
Comments: typo, sense wrong
Status: didn't come up Mar 89 X3J13; withdraw?
+ TIME-ZONE-NON-INTEGER
Version 1, 13-Mar-89, Released 16-Mar-89
Version 2, 10-Apr-89, as amended Mar 89 X3J13 (not released, on arisia)
Status: passed, as amended, Mar 89 X3J13
* TYPE-OF-UNDERCONSTRAINED
Version 3, 12-Dec-88, Released 12 Dec 88
Comments: Accepted, with amendments
Version 5, 16-Mar-89
Comments: Moon's comments, only some responses. Fix
Status: need new version
* UNDEFINED-VARIABLES-AND-FUNCTIONS
Synopsis: What happens on an undefined function call, unbound variable ref?
Version 1, 29-Nov-88, Released 11-Jan-89
Comments: offline discussion about SLOT-UNBOUND
Status: ? didn't get to; withdraw?
+ UNREAD-CHAR-AFTER-PEEK-CHAR
Version 2, 2-Dec-88, Released 12-Dec-88
Status: passed, Jan 89 X3J13
+ VARIABLE-LIST-ASYMMETRY
Version 3, 08-Oct-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13
+ WITH-OUTPUT-TO-STRING-APPEND-STYLE
Version 5, 7-JUN-88
Status: Passed, 1988
* WITH-OPEN-FILE-DOES-NOT-EXIST
Version 1, 17-Mar-89
Status: didn't get to; withdraw?
∂10-Apr-89 1303 CL-Cleanup-mailer Issue: LOAD-TRUENAME (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 10 Apr 89 13:02:56 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 574569; Mon 10-Apr-89 16:02:52 EDT
Date: Mon, 10 Apr 89 16:02 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TRUENAME (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890410160211.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
This is not just a report on what happened at the meeting.
In this version, I did the following:
- Merged my `proposed amendments.'
- Ignored Moon's version 2 by his request. It was only very slightly
different than my `proposed amendments,' which he liked better.
- Changed the description of the ...-PATHNAME* variables to say they
hold a pathname that has already been merged with the defaults by
LOAD and COMPILE-FILE.
The Proposal and Rationale are the only sections which changed since v1.
-kmp
-----
Issue: LOAD-TRUENAME
Forum: Cleanup
References: LOAD (p426), PROVIDE (p188), REQUIRE (p188),
Issue REQUIRE-PATHNAME-DEFAULTS
Category: ADDITION
Edit history: 13-Mar-89, Version 1 by Pitman
29-Mar-89, Version 2 by Moon (add -PATHNAME vars)
10-Apr-89, Version 3 by Pitman (clarify v2)
Problem Description:
It is difficult to construct sets of software modules which work
together as a unit and which port between different implementations.
REQUIRE and PROVIDE were intended to provide this level of support
but have `failed' to be portable in practice.
Typical user configurations involve a `system definition' file which
loads the modules of a `system' (collection of software modules).
Among the specific problems which arise are:
- File system types may vary. Different file syntax must be used for
each site.
- Even with the same Lisp implementation and host file system type,
the directory in which a software system resides may differ from
delivery site to delivery site.
- Multiple `copies' of the same system may reside in different
directories on the same machine.
Proposal (LOAD-TRUENAME:NEW-PATHNAME-VARIABLES):
Introduce new variables:
*LOAD-TRUENAME* [Variable]
This special variable is initially NIL, but is bound by LOAD to
hold the truename of the pathname of the file being loaded.
*COMPILE-FILE-TRUENAME* [Variable]
This special variable is initially NIL, but is bound by
COMPILE-FILE to hold the truename of the pathname of the file
being compiled.
*LOAD-PATHNAME* [Variable]
This special variable is initially NIL but is bound by LOAD
to hold a pathname which represents the filename given as the
first argument to LOAD merged against the defaults.
That is, (PATHNAME (MERGE-PATHNAMES arg1)).
*COMPILE-FILE-PATHNAME* [Variable]
This special variable is initially NIL but is bound by COMPILE-FILE
to hold a pathname which represents the filename given as the
first argument to COMPILE-FILE merged against the defaults.
That is, (PATHNAME (MERGE-PATHNAMES arg1)).
Example:
------ File SETUP ------
(IN-PACKAGE 'MY-STUFF)
(DEFMACRO COMPILE-TRUENAME () `',*COMPILE-FILE-TRUENAME*)
(DEFVAR *SOURCE-FILE* (COMPILE-TRUENAME) "Just for debugging.")
(DEFVAR *LOADED-FILE* *LOAD-TRUENAME*)
(DEFUN LOAD-MY-SYSTEM ()
(DOLIST (MODULE-NAME '("FOO" "BAR" "BAZ"))
(LOAD (MERGE-PATHNAMES MODULE-NAME *LOAD-TRUENAME*))))
------------------------
(LOAD "SETUP")
(LOAD-MY-SYSTEM)
Rationale:
This satisfies the most common instances of the frequently reported
problem in the Problem Description.
The ...-TRUENAME* variables are useful to tell the real file being
loaded.
The ...-PATHNAME* variables are useful to find information about
the original link names or logical device names mentioned in the
pathname to be opened but no longer reflected in the truename.
Note that it is not adequate to just have the -PATHNAME* variables
since TRUENAME on these pathnames might not yield the value of the
-TRUENAME* variables if the file has been deleted or protected
since the open occurred (in some implementations).
Current Practice:
Wide variation.
In some implementations, calling LOAD binds or sets
*DEFAULT-PATHNAME-DEFAULTS* so that pathnames named in a file being
LOADed will default to being `nearby.'
Some implementations provide special variables that are similar or
identical to one or both of those proposed.
Some implementations have a way to represent the pathname for the
current working directory, and make the default pathname default
to that, so that loading without specifying a default again tends to
get `nearby' files.
None of these techniques is portable, unfortunately, because there
is no agreement.
Cost to Implementors:
Very small.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Continued difficulty for anyone trying to put a system of modules
in a form where they can be conveniently delivered using portable code.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
Negligible.
Discussion:
Touretzky raised the issue most recently on Common-Lisp. A number
of people immediately jumped on the bandwagon, indicating it was
important to them, too.
Pitman made three suggestions in response, of which the above is
the first. The others included:
2. Variables *LOAD-TRUENAMES* and *COMPILE-FILE-TRUENAMES* which hold
lists of the truenames of all files being loaded or compiled,
respectively, during the dynamic invocation of LOAD and COMPILE-FILE.
3. Variable *LOAD-OR-COMPILE-FILE-TRUENAMES* which holds a list like
((LOAD truename) (COMPILE-FILE truename) ...)
during the dynamic invocation of LOAD and COMPILE-FILE.
Touretzky responded:
``I like KMP's proposals. I like the second one best: have separate
variables for files being loaded and files being compiled, and use
them to maintain a stack so we can see the nesting of loads within
files.''
Pitman ultimately chose to present the first rather than the second
because it seemed simpler, easier to explain, and more likely to
pass at this late date.
∂10-Apr-89 1349 CL-Cleanup-mailer Issue: LOAD-TRUENAME (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 10 Apr 89 13:49:07 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 574621; Mon 10-Apr-89 16:48:51 EDT
Date: Mon, 10 Apr 89 16:48 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TRUENAME (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890410160211.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890410204842.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
I approve this version. I checked it against the amendment
I had proposed.
In the example section,
(LOAD (MERGE-PATHNAMES MODULE-NAME *LOAD-TRUENAME*))))
should be
(LOAD (MERGE-PATHNAMES MODULE-NAME *LOAD-PATHNAME*))))
That's the whole reason for the amendment to add *LOAD-PATHNAME*!
The discussion section ought to include someone's suggestion that all
these variables could be replaced by *LOAD-STREAM* and
*COMPILE-FILE-STREAM*, combined with the existing PATHNAME and TRUENAME
functions. It should also include someone else's suggestion that those
two variables could be replaced by *STANDARD-INPUT*. I think there was
some argument against allowing access to the stream that convinced me to
support this proposal instead, but that other suggestion ought to be
given fair representation.
∂10-Apr-89 1621 CL-Cleanup-mailer Issue: PATHNAME-CANONICAL-TYPE
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 10 Apr 89 16:21:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 574802; Mon 10-Apr-89 19:21:01 EDT
Date: Mon, 10 Apr 89 19:20 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-CANONICAL-TYPE
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19890410232048.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Larry suggests a simpler proposal than Kent's. Here is some background
on pathname canonical types in general:
There are three purposes served by pathname canonical types:
(1) Construction. There is currently no portable way to construct a
pathname that follows local file naming conventions. For example, given
a program named "foo", we'd like to construct the conventional names for
its source and compiled files. These will be "foo.l" and "foo.b" on one
system, "FOO.LSP" and "FOO.BIN" on another system, and "foo.lisp" and
"foo.ibin" on a third system.
More generally, we would like to be able to access naming conventions
for many types of files, not just Lisp source and compiled Lisp. A
simplifying assumption is that all naming conventions affect only the
type field. Thus a facility to translate canonical types into actual
types is sufficient. Another assumption is that a given file system
always uses the same actual type for a given class of file; Symbolics
pathname canonical types are more general than this, but that is not
being proposed here, as it was primarily useful only in connection with
a transition between different releases of Unix, an application too
specialized to be enshrined in Common Lisp.
We would also like users to be able to define new classes of files of
their own, with associated file-system-dependent naming conventions.
For example, if I write a portable `defsystem', I would use a unique
naming convention for the file in which it stores its configuration
database. The naming convention might not use the same string on every
file system, so it should be a canonical type.
(2) Recognition. There is currently no portable way to classify a file
from its pathname. If I write a portable editor, I would like to be
able to recognize the syntax of a program source file from its pathname
type field (Lisp, C, Ada, etc.) The same table of local file naming
conventions used in part 1 can be accessed in reverse to translate an
actual type to a canonical type. The editor can then look up the
canonical type in a table of known languages.
There is a tension here between two goals when there are subclasses of
files. Consider two systems that can cross-compile for each other.
This clearly involves two canonical types for compiled Lisp files.
Should the canonical type reflect the system for which the file was
compiled, so that the canonical type of a particular file has the same
value in both systems? Or should both systems use the same canonical
type for files compiled to be loaded locally, so that the canonical type
of a particular usage of a file has the same value in both systems?
(3) Translation. There is currently no portable way to translate a
pathname written in the file naming conventions of one file system into
a pathname written in the file naming conventions of a different file
system. A trivial use for this is cross-host pathname defaulting and
merging in a heterogeneous network, e.g. so a portable copy file command
can default the output file name intelligently. A much more important
use is in logical pathnames (logical pathnames are a universal file
system that is mapped into the locally available file system through
site-dependent translations; this is primarily useful in software
distribution), where it is necessary to translate accurately between
logical pathname file naming conventions and local file naming
conventions. The table of file naming conventions used in part 1 can be
accessed in reverse to identify the canonical type of a logical
pathname, and then accessed forwards to translate to the actual type to
be used on the local file system.
Whether we want Common Lisp to support these three features in a
portable fashion is of course a matter of policy. Omitting any or all
of the features does not make the language unusable, it just means two
things: Users writing programs not intended to be portable will build
the local conventions directly into their programs, causing problems
later if they change their minds about portability. Every user writing
a portable program that needs such capabilities has to implement them
himself, or obtain them from some supplier other than the Common Lisp
language, which will produce a small non-portable appendage to the
program that has to be redone for each port.
Critique of the proposals:
Larry's proposal addresses only the first paragraph of part 1. It
does not allow user definition of file naming conventions and does
not support recognition or translation at all.
Kent's proposal addresses part 2 and the first paragraph of part 1.
It probably extends trivially to address part 3 as well, by adding
a statement that MERGE-PATHNAMES uses canonical types to merge
the type field.
As noted in the discussion section of the proposal, I would prefer
a proposal that addressed all three parts, which would require a
way to name file system types. We could follow the standard defined
by the Internet Domain Name system.
∂11-Apr-89 0714 CL-Cleanup-mailer Issue: LOAD-TRUENAME (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 11 Apr 89 07:14:20 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 575061; Tue 11-Apr-89 10:12:53 EDT
Date: Tue, 11 Apr 89 10:12 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TRUENAME (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890411101208.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
New version to accomodate Moon's comments.
I changed the Example a bit.
I added a paragraph to the Discussion.
Everything else is the same.
I'm hoping this is a final version.
-kmp
-----
Issue: LOAD-TRUENAME
Forum: Cleanup
References: LOAD (p426), PROVIDE (p188), REQUIRE (p188),
Issue REQUIRE-PATHNAME-DEFAULTS
Category: ADDITION
Edit history: 13-Mar-89, Version 1 by Pitman
29-Mar-89, Version 2 by Moon (add -PATHNAME vars)
10-Apr-89, Version 3 by Pitman (clarify v2)
11-Apr-89, Version 4 by Pitman (merge Moon's v3 comments)
Problem Description:
It is difficult to construct sets of software modules which work
together as a unit and which port between different implementations.
REQUIRE and PROVIDE were intended to provide this level of support
but have `failed' to be portable in practice.
Typical user configurations involve a `system definition' file which
loads the modules of a `system' (collection of software modules).
Among the specific problems which arise are:
- File system types may vary. Different file syntax must be used for
each site.
- Even with the same Lisp implementation and host file system type,
the directory in which a software system resides may differ from
delivery site to delivery site.
- Multiple `copies' of the same system may reside in different
directories on the same machine.
Proposal (LOAD-TRUENAME:NEW-PATHNAME-VARIABLES):
Introduce new variables:
*LOAD-TRUENAME* [Variable]
This special variable is initially NIL, but is bound by LOAD to
hold the truename of the pathname of the file being loaded.
*COMPILE-FILE-TRUENAME* [Variable]
This special variable is initially NIL, but is bound by
COMPILE-FILE to hold the truename of the pathname of the file
being compiled.
*LOAD-PATHNAME* [Variable]
This special variable is initially NIL but is bound by LOAD
to hold a pathname which represents the filename given as the
first argument to LOAD merged against the defaults.
That is, (PATHNAME (MERGE-PATHNAMES arg1)).
*COMPILE-FILE-PATHNAME* [Variable]
This special variable is initially NIL but is bound by COMPILE-FILE
to hold a pathname which represents the filename given as the
first argument to COMPILE-FILE merged against the defaults.
That is, (PATHNAME (MERGE-PATHNAMES arg1)).
Example:
------ File SETUP ------
(IN-PACKAGE "MY-STUFF")
(DEFMACRO COMPILE-TRUENAME () `',*COMPILE-FILE-TRUENAME*)
(DEFVAR *MY-COMPILE-TRUENAME* (COMPILE-TRUENAME) "Just for debugging.")
(DEFVAR *MY-LOAD-PATHNAME* *LOAD-PATHNAME*)
(DEFUN LOAD-MY-SYSTEM ()
(DOLIST (MODULE-NAME '("FOO" "BAR" "BAZ"))
(LOAD (MERGE-PATHNAMES MODULE-NAME *MY-LOAD-PATHNAME*))))
------------------------
(LOAD "SETUP")
(LOAD-MY-SYSTEM)
Rationale:
This satisfies the most common instances of the frequently reported
problem in the Problem Description.
The ...-TRUENAME* variables are useful to tell the real file being
loaded.
The ...-PATHNAME* variables are useful to find information about
the original link names or logical device names mentioned in the
pathname to be opened but no longer reflected in the truename.
Note that it is not adequate to just have the -PATHNAME* variables
since TRUENAME on these pathnames might not yield the value of the
-TRUENAME* variables if the file has been deleted or protected
since the open occurred (in some implementations).
Current Practice:
Wide variation.
In some implementations, calling LOAD binds or sets
*DEFAULT-PATHNAME-DEFAULTS* so that pathnames named in a file being
LOADed will default to being `nearby.'
Some implementations provide special variables that are similar or
identical to one or both of those proposed.
Some implementations have a way to represent the pathname for the
current working directory, and make the default pathname default
to that, so that loading without specifying a default again tends to
get `nearby' files.
None of these techniques is portable, unfortunately, because there
is no agreement.
Cost to Implementors:
Very small.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Continued difficulty for anyone trying to put a system of modules
in a form where they can be conveniently delivered using portable code.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
Negligible.
Discussion:
Touretzky raised the issue most recently on Common-Lisp. A number
of people immediately jumped on the bandwagon, indicating it was
important to them, too.
Pitman made three suggestions in response, of which the above is
the first. The others included:
2. Variables *LOAD-TRUENAMES* and *COMPILE-FILE-TRUENAMES* which hold
lists of the truenames of all files being loaded or compiled,
respectively, during the dynamic invocation of LOAD and COMPILE-FILE.
3. Variable *LOAD-OR-COMPILE-FILE-TRUENAMES* which holds a list like
((LOAD truename) (COMPILE-FILE truename) ...)
during the dynamic invocation of LOAD and COMPILE-FILE.
Touretzky responded:
``I like KMP's proposals. I like the second one best: have separate
variables for files being loaded and files being compiled, and use
them to maintain a stack so we can see the nesting of loads within
files.''
Pitman ultimately chose to present the first rather than the second
because it seemed simpler, easier to explain, and more likely to
pass at this late date.
Other suggestions which were considered discarded were:
a. Provide just variables *LOAD-STREAM* and *COMPILE-FILE-STREAM*.
Then PATHNAME and TRUENAME could be used to yield the
information contained in the -PATHNAME* and -TRUENAME* variables
of the proposal above.
b. Like (a), but call both variables *STANDARD-INPUT*. That is,
say that LOAD and COMPILE-FILE bind *STANDARD-INPUT* to the
stream being loaded.
There were a number of pitfalls with this approach which all center
around the way it invites the user to do other operations besides
PATHNAME and TRUENAME. Not only would some people be confused by
the difference between the characteristics of *LOAD-STREAM* for
compiled and interpreted files, but also even with interpreted
streams, the actual position of the stream pointer at the time of
execution of the forms contained in the file could vary between
implementations in a way that became a lurking portability barrier.
Since the observed user need which spawned this discussion was for
a way to tell what file was being loaded and not for a way to
manipulate the stream, it seemed best to just go with the variables
that addressed that specific need--fewer pitfalls and more perspicuous
code are likely to result.
∂11-Apr-89 2155 CL-Cleanup-mailer Re: Issue: PATHNAME-CANONICAL-TYPE
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Apr 89 21:55:01 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 11 APR 89 21:54:37 PDT
Date: 11 Apr 89 21:53 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-CANONICAL-TYPE
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Mon, 10 Apr 89 19:20 EDT
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@sail.stanford.edu
Message-ID: <890411-215437-9502@Xerox>
I like your analysis. My argument is that the first paragraph of (1) is the
"most important", and is the only one that I think can be solved. While we
can make some requirements on lisp system's naming conventions, e.g., that
the naming convention that distinguishes a Lisp source and compiled Lisp
must affect only the type field, we can't require that of other
applications. Since your "assumptions" are often false ("all naming
conventions affect only the type field", "a given file system always uses
the same actual type for a given class of file"), a design which presumes
they are true are not good canditates for the standard.
Similarly, there are numerous file systems where there is no good canonical
mapping from pathname-type to actual knowledge of the kind of file, and so
the prerequesites are not satisifed for being able to do recognition and
translation based merely on pathname-type. (I'm thinking of the Macintosh,
where the actual file type is frequently encoded not in the pathname but
rather in the 'creator' and 'type' fields, and DOS, where the three
character limit means that the same pathname-type is frequently used for
different interpretations by different applications, and some Xerox
systems, where the actual file type is encoded by a 16-bit file attribute,
etc.)
I don't think it is merely a matter of policy whether Common Lisp should
support all three features; I think it is also a matter of feasibility. If
supporting the features is in fact impossible in many file systems, we
shouldn't require them to be supported. Since Lisp implementors have
control over the file types used by their compiler, we can require
canonical values for make-pathname, however.
∂12-Apr-89 1012 CL-Cleanup-mailer issue PRETTY-PRINT-INTERFACE
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 12 Apr 89 10:12:12 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA07535; Wed, 12 Apr 89 11:12:05 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA03186; Wed, 12 Apr 89 11:12:03 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904121712.AA03186@defun.utah.edu>
Date: Wed, 12 Apr 89 11:12:02 MDT
Subject: issue PRETTY-PRINT-INTERFACE
To: cl-cleanup@sail.stanford.edu
I've finally found time to look over the hardcopy of this issue that
was distributed at the March meeting, but I'm having an extremely
difficult time parsing it. The description is spread out in too many
places (the proposal section, the list of amendments, and the attached
document), and there are some things mentioned in the discussion
section that appear to contradict what is actually in the proposal
(like whether the list form of the CONS type specifier is a real type
specifier or not). Can somebody please revise this writeup so that it
is organized more coherently? I realize this issue is long and
complicated, but improving the presentation would make it a lot more
understandable.
-Sandra
-------
∂14-Apr-89 0700 CL-Cleanup-mailer Status of CL Condition Handling
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 14 Apr 89 07:00:00 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 577300; Fri 14-Apr-89 10:00:03 EDT
Date: Fri, 14 Apr 89 09:59 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Status of CL Condition Handling
To: CL-Cleanup@SAIL.Stanford.EDU, CL-Error-Handling@SAIL.Stanford.EDU
cc: Gateley@tilde.csc.ti.com
In-Reply-To: <2817520854-15094035@Casablanca>
Message-ID: <890414095910.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Messages like the following are increasingly common these days.
Date: Thu, 13 Apr 89 23:40:54 CDT
From: John Gateley <Gateley@tilde.csc.ti.com>
Subject: CLEH
Could you send me a pointer to the latest description of CLEH? I have
the 3/12/88 version of 'Condition System Revision 18'?
I checked with David Bartley, our representative to X3J13 and he doesn't
have anything more recent.
I really don't mind fielding this sort of question and have been doing so
for a long time, but since it has been asked a lot lately, I'm sending this
one-shot message just so there will be a recent message that people can
refer to when bringing others up to date.
----- Status of Condition Handling in Common Lisp, April 1989 -----
The most current revision of the error handling document is
Common Lisp Condition System, Version 18. This document was voted
in to CL (in the same sense as CLOS and LOOP have been) and in my
mind it occupies essentially the same status in the standard as
does CLtL. That is, it has been affected by and may be further
affected by action of the Cleanup committee. The effect of its
acceptance was not to cast it in concrete and prohibit change,
but rather to establish that the default is that what it says will
end up in the standard unless someone acts to change that default.
Until the standard is finally voted in as a single unit, nothing is
a certainty.
Version 18 of the condition proposal document is available from
AI.AI.MIT.EDU in the file named "COMMON;COND18 TEXT".
A `sample implementation' is available from AI.AI.MIT.EDU in the
file named "COMMON;COND18 LISP". The sample implementation is not
binding on the proposal text. It is merely `recommended reading'
for anyone who is about to implement the proposal.
With the advent of the proposal's adoption by X3J13 last fall, the
the error handling subcommittee was effectively disbanded. I seem
to still be handling some of what would have been its business, but
I no longer formally consider the group to be an active one or myself
to be the moderator. Changes since the proposal have been and are
being handled by the Cleanup committee.
The window is closed for most Cleanup changes which are feature
additions. The effect of this is that CL-ERROR-HANDLING@SAIL.STANFORD.EDU
is a dormant list. As cleanup items are approved, no new central
error handling document is being produced to minimize administrative
overhead. The approved items will be directly absorbed by the full
standard document itself.
At this point, the only changes being seriously considered by Cleanup
are `essential functionality' that has slipped through the cracks,
or `clarifications' and `bug fixes.'
The cleanup items which are of most interest are:
CLOS-CONDITIONS - Version 4, option INTEGRATE was adopted at the
Mar-89 meeting.
ERROR-CHECKING-IN-NUMBERS-CHAPTER - A proposal for what conditions
should be signalled (and when) by the functions in the numbers
chapter. This will be discussed at the next X3J13 meeting. Other
proposals of similar kind may appear at that time as well.
CONDITION-RESTARTS - A proposal for associating conditions with
restarts. This has been a long-acknowledged weakness in the
condition system. This proposal will come up in some form at the
next X3J13 meeting, but will probably change before it does.
Some changes under consideration:
- Eliminate the proposed COPY-CONDITION function
- Eliminate SIGNAL-WITH-RESTARTS in favor of a change to
RESTART-CASE that makes it automatically create an association
when its first `argument' is a SIGNAL, WARN, ERROR, or CERROR
expression.
- Change the syntax of WITH-CONDITION-RESTARTS to get
condition-form and restarts-form as two arguments instead of
as one argument with funny syntax.
These cleanup items are generally available via anonymous FTP from
ARISIA.XEROX.COM in the directories /clcleanup/pending/ and
/clcleanup/passed/, depending on whether they are pending or passed.
Cleanup items for which there is some interest but not yet any proposal
are:
CONDITIONS-PACKAGE - Some people think the LISP package (now the
COMMON-LISP package, I guess, since a recent vote on issue
LISP-PACKAGE-NAME) is too cluttered and that we should make a new
package for some of the CONDITIONS stuff. (Many of the same people
think the same about CLOS, by the way.)
CONDITION-METACLASS - We've never specified the metaclass of
conditions so right now you can really only safely mix together
condition classes with other condition classes. People have
expressed interest in doing other kinds of mixing, which would
require knowing the metaclass of objects of class CONDITION.
If this leaves unanswered questions about any of this and you are
not an X3J13 representative, please direct them first to the X3J13
rep from your organization. If you have no rep or if your rep can't
answer your question (or if you are the rep and can't answer your own
question :-), you can direct your queries directly to me if you don't
consider them of broad interest and just want them handled privately.
∂17-Apr-89 1301 CL-Cleanup-mailer [Robert S. Boyer <boyer@CLI.COM>: Fast IO]
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Apr 89 13:01:31 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 17 APR 89 12:44:48 PDT
Date: 17 Apr 89 12:44 PDT
From: masinter.pa@Xerox.COM
Subject: [Robert S. Boyer <boyer@CLI.COM>: Fast IO]
To: cl-cleanup@sail.stanford.edu
cc: wfs@CLI.COM, boyer@CLI.COM
reply-to: cl-cleanup@sail.stanford.edu, wfs@CLI.COM, boyer@CLI.COM
Message-ID: <890417-124448-22081@Xerox>
If two implementations need some declaration for 'simple' streams so that
READ-CHAR and friends can be fast, maybe this is a more generally felt
need? I thought I'd go ahead and forward to a wider forum....
----- Begin Forwarded Messages -----
Date: Mon, 17 Apr 89 14:31:51 CDT
From: Robert S. Boyer <boyer@CLI.COM>
To: masinter.pa
Cc: wfs@CLI.COM, jonl@lucid.com
Subject: Fast IO
Reply-To: boyer@cli.com
Sorry for not being informative about read-char, fast-read-char, and
:in-line.
In both Lucid and AKCL, it takes about 60 microseconds on a Sun-3/280
to do a read-char or read-byte in the usual case. That is a lot of
time! I am not really sure why it should take so long, but it does.
Something about doing necessary checking that the stream is not fancy,
bidirectional, etc., etc. (I am not making exact timing remarks here
-- just ballpark.)
Of course, in Unix on a Sun-3/280, the C programmer can get a
character in a couple of microseconds (again, ballpark). So both
Lucid and AKCL have non-CLTL extensions to make it possible to move
characters at microsecond speeds. Lucid does this by defining 6
functions that have a "fast-" prefix, e.g. fast-read-char. AKCL
(1.112) adds a new declaration (:in-line) whose semantics is something
like "I hereby assert that here is a really simple sort of stream and
I want the AKCL compiler to therefore lay down fast code for
read-char".
If these explanations don't suffice, I'm in over my head. I am
speaking here just as a user, not an implementor; but I am a user who
sees the necessity of a fast way to read characters in any Common
Lisp. I suspect that since both AKCL and Lucid have run into this
problem, other von Neumann machine Lisps will too. (In fact, my
recollection is that read-char stood a lot of room for speeding up on
Lispms, too, perhaps for the same reasons.)
I personally like the AKCL idea of somehow adding a declaration that a
stream is "simple". As it is, in our theorem-prover code we now do a
(proclaim '(declaration :in-file)), which, as I understand it, means
that :in-file declarations will be ignored by, say, the Lucid compiler
or any other compiler that doesn't know about :in-line. read-char
will go fast in AKCL, but the code will also work in Lucid. If we
were to use Lucid's fast-read-char, say, that would work for Lucid but
we would need dialect conditionals defining such a function to get
fast-read-char to work in other Lisps besides Lucid. We abhor dialect
conditionals.
I would much prefer a CLTL uniform nomenclature, any nomenclature,
fast-read-char, :in-line, or anything else.
Thanks,
Bob
P.S. If you have any serious questions about :in-line, I suspect that
Schelter (wfs@cli.com) will be happy to answer them.
----- End Forwarded Messages -----
∂19-Apr-89 0707 CL-Cleanup-mailer [Robert S. Boyer <boyer@CLI.COM>: Fast IO]
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 19 Apr 89 07:07:32 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 580833; Tue 18-Apr-89 19:20:16 EDT
Date: Tue, 18 Apr 89 19:20 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: [Robert S. Boyer <boyer@CLI.COM>: Fast IO]
To: cl-cleanup@sail.stanford.edu, wfs@CLI.COM, boyer@CLI.COM
In-Reply-To: <890417-124448-22081@Xerox>
Message-ID: <19890418232014.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Symbolics Genera is even slower at read-char. But I don't think a
declaration is the answer. I believe that if we wanted to make
read-char fast on streams where it can be fast (simple buffered
streams), a simple-stream declaration would not add any significant
additional speed. It might save about 2 microseconds for an indirect
call. This is assuming that compatibility with past implementations
of streams was not an issue (and I don't think it's reasonable in
designing a new language to assume that such would be an issue).
I know that Symbolics Genera read-char is slow because we haven't
made any effort to make it fast, not because non-simple streams make
it impossible to make it fast. I can't speak for Lucid but I wouldn't
be surprised if the story is the same for them. So I'd oppose adding
anything to the language in this area. Instead, customers should signal
to implementors their discontent with the current quality of implementation
of read-char. Implementors can then raise the priority of that and
possibly shift resources from other things.
∂19-Apr-89 1519 CL-Cleanup-mailer no :in-file
Received: from CLI.COM by SAIL.Stanford.EDU with TCP; 19 Apr 89 15:18:54 PDT
Received: by CLI.COM (4.0/1); Wed, 19 Apr 89 17:15:32 CDT
Date: Wed, 19 Apr 89 17:15:32 CDT
From: Robert S. Boyer <boyer@CLI.COM>
Message-Id: <8904192215.AA03885@CLI.COM>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu, wfs@CLI.COM
Subject: no :in-file
Reply-To: boyer@cli.com
I now concur with Moon's view that stream declarations are unnecessary
in principle, especially in view of the fact that Bill Schelter has
now implemented very fast (couple of microsecond)
read/write//char-byte in AKCL without the necessity of declarations or
specially named functions.
∂19-Apr-89 1528 CL-Cleanup-mailer [Robert S. Boyer <boyer@CLI.COM>: Fast IO]
Received: from CLI.COM by SAIL.Stanford.EDU with TCP; 19 Apr 89 15:28:36 PDT
Received: by CLI.COM (4.0/1); Wed, 19 Apr 89 17:24:42 CDT
Date: Wed, 19 Apr 89 17:24:42 CDT
From: Bill Schelter <wfs@CLI.COM>
Message-Id: <8904192224.AA03946@CLI.COM>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu, boyer@CLI.COM
In-Reply-To: David A. Moon's message of Tue, 18 Apr 89 19:20 EDT <19890418232014.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: [Robert S. Boyer <boyer@CLI.COM>: Fast IO]
Reply-To: wfs@cli.com
I had originally felt it might be a good idea to have a specialized
type of stream for faster io in common lisp, but now am in accord with
Moon that this is simply not necessary.
Just before receiving his message I had finished reworking the
write-byte/write-char and read-byte/read-char WITHOUT declarations, so
they are now in the 2 to 3 microsecond range respectively, in
AKCL(version 1.116) on a sun3/280. The difference between this and
what I could do with a specialized stream was practically not possible
to time, when reading or writing a million characters. Of course
streams other than file streams and interprocess streams are still
substantially slower, but that is probably reasonable (for the
moment..).
Bill Schelter
∂19-Apr-89 1557 CL-Cleanup-mailer no :in-file
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 Apr 89 15:54:32 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA11844g; Wed, 19 Apr 89 15:54:11 PDT
Received: by blacksox id AA01834g; Wed, 19 Apr 89 15:53:40 PDT
Date: Wed, 19 Apr 89 15:53:40 PDT
From: Eric Benson <eb@lucid.com>
Message-Id: <8904192253.AA01834@blacksox>
To: boyer@cli.com
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@sail.stanford.edu,
wfs@CLI.COM
In-Reply-To: Robert S. Boyer's message of Wed, 19 Apr 89 17:15:32 CDT <8904192215.AA03885@CLI.COM>
Subject: no :in-file
However, in order to be competitive with C in speed it would be useful
to be able to do the following:
For binary streams, declare the element-type of the stream, e.g. allow
the STREAM type specifier to take an optional element-type like ARRAY
and COMPLEX.
For binary streams, functions to read and write arrays in a single
chunk. Lucid supplies READ-ARRAY and WRITE-ARRAY as extensions.
For character input, a destructive version of READ-LINE.
∂19-Apr-89 1621 CL-Cleanup-mailer no :in-file
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 19 Apr 89 16:21:42 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 581565; Wed 19-Apr-89 19:21:33 EDT
Date: Wed, 19 Apr 89 19:21 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: no :in-file
To: Eric Benson <eb@lucid.com>
cc: boyer@cli.com, cl-cleanup@sail.stanford.edu, wfs@CLI.COM
In-Reply-To: <8904192253.AA01834@blacksox>
Message-ID: <19890419232148.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 19 Apr 89 15:53:40 PDT
From: Eric Benson <eb@lucid.com>
However, in order to be competitive with C in speed it would be useful
to be able to do the following:
For binary streams, declare the element-type of the stream, e.g. allow
the STREAM type specifier to take an optional element-type like ARRAY
and COMPLEX.
I see no harm in this, if someone wants to propose it. I'm not sure
whether Symbolics would use it, but I think it's a reasonable thing
for imaginable implementations to want.
For binary streams, functions to read and write arrays in a single
chunk. Lucid supplies READ-ARRAY and WRITE-ARRAY as extensions.
For character input, a destructive version of READ-LINE.
Symbolics Genera has the equivalent of all of these under different
names. The read-array and write-array (shouldn't they be called
read-vector and write-vector?) are generic and work for character
streams as well, given a string as the vector. Someone should write
a proposal for these features. It might or might not be too late
to add this to X3J13 Common Lisp, but at least everybody could use
compatible names for their extensions.
∂20-Apr-89 1454 CL-Cleanup-mailer Issue: THE-VALUES [was: intent of (THE <type> <expression>)]
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 20 Apr 89 14:54:19 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 582196; Thu 20-Apr-89 17:54:13 EDT
Date: Thu, 20 Apr 89 17:53 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: THE-VALUES [was: intent of (THE <type> <expression>)]
To: gls@Think.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8904202059.AA00383@joplin.think.com>
Message-ID: <890420175328.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
[Outside world removed.]
Date: Thu, 20 Apr 89 16:59:15 EDT
From: Guy Steele <gls@Think.COM>
...
PROPOSAL:
What it boils down to, is that THE should check only as many types
as requested (and pass back only as many).
No, this is not cool. THE is supposed to act purely as a declaration,
but you are changing it to require it to pass on only as many values
as the type specifer indicates. This could change the semantics of
a suitably devious program.
Better to say that it checks as many types as requsted, but passes on
exactly the values it receives.
--Guy
Even though I agree with your position, I think it's worth our writing up
a clarification issue to make sure we're all agreed and that it's 100% clear
in the ANSI spec.
∂20-Apr-89 2003 CL-Cleanup-mailer Issue: ERROR-TERMINOLOGY (final amended version ??? Version 9)
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 20 Apr 89 20:03:37 PDT
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88);
Thu, 20 Apr 89 22:04:03 CDT id AA13750 for cl-cleanup@sail.stanford.edu
Posted-Date: Thu, 20 Apr 89 22:02:30 CDT
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
id AA08661; Thu, 20 Apr 89 22:02:30 CDT
Date: Thu, 20 Apr 89 22:02:30 CDT
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8904210302.AA08661@pavo.src.honeywell.com>
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: chapman%aitg.DEC@decwrl.dec.com's message of 18 Apr 89 13:19 <8904181723.AA03079@decwrl.dec.com>
Subject: Issue: ERROR-TERMINOLOGY (final amended version ??? Version 9)
>IMPLEMENTATIONS MAY BE EXTENDED An implementation is free to treat the
> situation in ANY ONE of the following ways: (1)
> When the situation occurs, an error should be
> signalled at least in safe code, OR (2) When the
> situation occurs, the "consequences are undefined",
> OR (3) When the situation occurs, the consequences are
Item (1) should either be:
When the situation occurs, an error "should be signalled",
Or simply deleted entirely since it is really a subset of (2)/(3)
>WARNING IS ISSUED A warning is issued, as described in WARN, in
> both safe and unsafe code when the situation
> is detected. Conforming code may rely on the
> fact that a warning will be issued in both
> safe and unsafe code when the situation is
> detected. Every implementation is required to
> detect this situation in both safe and unsafe
> code when the situation is detected. The
> presence of a warning will in no way alter the
> value returned by the form which caused the
> situation to occur. For example, "a warning is
> issued if a declaration specifier is not one
> of those defined in Chapter 9 of CLtL and has
> not been declared in a DECLARATION
> declaration."
"Every implementation is required to detect this situation in both safe and
unsafe code." (i.e. delete the "when the situation is detected").
Also; "The presence of a warning will in no way alter the value
returned..." is a little strong. I think some weasel words like "in the
absence of handlers for contitions of type warning, the presence of a
warning will ...". Unless of course we intend to disallow users from
setting up handlers for warnings that throw out, which would of course
change the value returned since there wouldn't be any.
∂24-Apr-89 1249 CL-Cleanup-mailer Issue COMPLEX-RATIONAL-RESULT, version 2
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 24 Apr 89 12:49:27 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 583636; Mon 24-Apr-89 15:48:28 EDT
Date: Mon, 24 Apr 89 15:48 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue COMPLEX-RATIONAL-RESULT, version 2
To: gls@THINK.COM, Masinter.pa@XEROX.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8904090537.AA00468@brigit.think.com>
Message-ID: <19890424194840.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
The opinion at Symbolics is that your version 2 is good. Let's
vote it in to replace the version 1 that X3J13 already voted in.
Should we take time in June to do this, or do it by letter?
Some TeX markup snuck into the proposal section, please remove it
before releasing.
The current practice section is out of date, since there are four
examples now. I'd change it to:
Symbolics Genera 7.4 returns a (complex single-float) for the first
example, returns 1 for the second example, and returns the specified
answers for the third and fourth examples. Other implementations were
not surveyed.
Guy if you'd like to survey some other implementations that could be
helpful.
∂28-Apr-89 0944 CL-Cleanup-mailer Issue COMPLEX-RATIONAL-RESULT, version 3
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 28 Apr 89 09:44:06 PDT
Received: from fafnir.think.com by Think.COM; Fri, 28 Apr 89 12:44:13 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 28 Apr 89 12:43:29 EDT
Received: from joplin.think.com by verdi.think.com; Fri, 28 Apr 89 12:43:26 EDT
From: Guy Steele <gls@Think.COM>
Received: by joplin.think.com; Fri, 28 Apr 89 12:43:24 EDT
Date: Fri, 28 Apr 89 12:43:24 EDT
Message-Id: <8904281643.AA05966@joplin.think.com>
To: cl-cleanup@sail.stanford.edu
Cc: gls@Think.COM
Subject: Issue COMPLEX-RATIONAL-RESULT, version 3
Version 3 fixes typos and surveys a few implementations.
Prologue to version 2 follows.
This was a good thing for Moon to bring up, but I think a couple
of desirable details were left uncovered. Here is a new version
to consider in June.
Detail 1 is that a mathematically rational or complex rational
value might result from arguments that are a mixture of rational
and complex rational; or a complex rational value might result
from arguments that are rational only.
Detail 2 is that the version 1 proposal mentions (complex float)
where I believe the more specific (complex single-float) is appropriate.
Detail 3 is that in some cases the option of an ordinary float
result is desirable or required rather than a (complex single-float);
consider the ABS function, for example.
Detail 4 is that if the true mathematical result is not rational
or complex rational, I think we want to specify that the returned
value is single-float or (complex single-float).
----------------------------------------------------------------
Issue: COMPLEX-RATIONAL-RESULT
References: CLtL p.203
Category: CLARIFICATION
Edit history: Version 1, 20-Mar-89, by Moon
Version 2, 08-Apr-89, by Steele
Version 2, 28-Apr-89, by Steele
Problem description:
Referring to irrational and transcendental functions, CLtL says:
When the arguments to a function in this section are all rational and
the true mathematical result is also (mathematically) rational, then
unless otherwise noted an implementation is free to return either an
accurate result of type rational or a single-precision floating-point
approximation. If the arguments are all rational but the result cannot
be expressed as a rational number, then a single-precision
floating-point approximation is always returned.
Referring to EXPT, CLtL says:
If the base-number is of type RATIONAL and the power-number is an
INTEGER, the calculation will be exact and the result will be of
type RATIONAL; otherwise a floating-point approximation may result.
What about arguments of type (complex rational)?
Proposal (COMPLEX-RATIONAL-RESULT:EXTEND):
Extend the paragraph quoted above as follows to cover the components
of complex numbers. If the arguments to a function are all of type
(OR RATIONAL (COMPLEX RATIONAL)) and the true mathematical result is
(mathematically) a complex number with rational real and imaginary
parts, then unless otherwise noted an implementation is free to return
either an accurate result of type (OR RATIONAL (COMPLEX RATIONAL)) or
a single-precision floating-point approximation of type SINGLE-FLOAT
(permissible only if the imaginary part of the true mathematical
result is zero) or (COMPLEX SINGLE-FLOAT). If the arguments are
all of type (OR RATIONAL (COMPLEX RATIONAL)) but the result cannot be
expressed as a rational or complex rational number, then the returned
value will be of type SINGLE-FLOAT (permissible only if the imaginary
part of the true mathematical result is zero) or (COMPLEX SINGLE-FLOAT).
For EXPT of a (COMPLEX RATIONAL) to an integer power, the
calculation must be exact and the result will be of type
(OR RATIONAL (COMPLEX RATIONAL)).
Examples:
[a] (log #c(-16 16) #c(2 2)) => 3 or approximately #c(3.0 0.0)
or approximately 3.0 (unlikely)
[b] (abs #c(3/5 4/5)) => 1 or approximately 1.0
[c] (expt #c(2 2) 3) => #c(-16 16)
[d] (expt #c(2 2) 4) => -64
Rationale:
This seems most consistent with the treatment of real numbers.
Current practice:
[a] [b] [c] [d]
Symbolics Genera 7.4 #c(3.00... 1.40...e-7) 1 #c(-16 16) -64
Sun Common Lisp 3.0.1 #c(3.0 2.61...e-16) 1.0 #c(-16 16) -64
KCL of 9/16/86 on VAX #c(3.0s0 -1.40...s-7) 1.0s0 #c(-16 16) -64
Allegro CL (Mac II) #c(3.0 2.05...e-16) 1.0 #c(-16 16) -64
Cost to Implementors:
Only EXPT would have to change, since the type of the other results
is at the discretion of the implementation.
Cost to Users:
Probably none, but it is hard to predict.
Cost of non-adoption:
Slightly less self-consistent language.
Performance impact:
None of any significance.
Benefits/Esthetics:
More self-consistent language.
Discussion:
None.
∂28-Apr-89 1426 CL-Cleanup-mailer ISSUE: GCD-LCM-ZERO-ARGS
Received: from hub.ucsb.edu (ucsbcsl.ucsb.edu) by SAIL.Stanford.EDU with TCP; 28 Apr 89 14:26:38 PDT
Received: from csilvax.ucsb.edu
by hub.ucsb.edu (5.59/UCSB-v2)
id AA22234; Fri, 28 Apr 89 14:27:18 PDT
Message-Id: <8904282127.AA22234@hub.ucsb.edu>
Received: from by csilvax.ucsb.CSNET (5.51) id AA14455; Fri, 28 Apr 89 14:25:34 PDT
Date: Fri, 28 Apr 89 14:25:34 PDT
From: Skona Brittain <skona%csilvax@hub.ucsb.edu>
Posted-Date: Fri, 28 Apr 89 14:25:34 PDT
To: CL-cleanup@SAIL.Stanford.edu
Subject: ISSUE: GCD-LCM-ZERO-ARGS
Cc: skona%csilvax@hub.ucsb.edu
Issue: GCD-LCM-ZERO-ARGS
References: CLtl pg.202 and Document 86-003 pg.3
Category: CHANGE
Edit history: Revision 1 by Skona Brittain 03/22/87
Revision 2 by Skona Brittain 01/06/89
Revision 3 by Skona Brittain 04/28/89 (removed references to
cases of no args to lcm)
Problem Description:
These functions are not well-defined for sets of arguments
that include the number zero.
Proposal (GCD-LCM-ZERO-ARGS:NOT-ALLOWED):
The arguments to lcm and gcd must be positive integers.
Test Case:
(lcm 1 0) would be an error instead of having the value 0.
Rationale:
Having the least common multiple of a set of numbers be less than
the least common multiple of a proper subset of that set
violates monotonicity. For example, monotonicity is violated by
(lcm 1 0) < (lcm 1) and (lcm 0) < (lcm).
Increasing the restrictions on the candidates for the lcm should
only be able to increase the value of the least qualifying one.
What the first example is saying is that the the least multiple
of 1 is 1 but the least number that is a multiple of both 1 and 0
is 0. This is patently ridiculous. Any reasoning that says that
0 is the lcm of 1 & 0 would also say that 0 is the lcm of 1 alone,
since 0 would be considered a multiple of 1 and is less than 1.
Furthermore, it would say that 0 is the result of the lcm operation
on any set of arguments at all. Although this would be mathematically
consistent, it would not make lcm a very useful operator.
The root of the problem is that it is unnatural to apply lcm or
gcd to anything but natural numbers. Negative numbers are not
having much of an effect because they are just being treated as
if they were their absolute values, i.e. the negativity of negative
arguments is ignored, but zero really screws things up. If it is
desired that zero be an allowed argument, it should also just be ignored,
(i.e passed over, the way nil in an association list is passed over)
Current Practice:
I know of no implementations that currently implement this change.
Cost to Users:
Very slight.
Cost to Implementors:
Very slight. Should lead to a reduction in code, since most algorithms
for computing gcd and lcm are for positive integers anyway.
Benefits:
see Esthetics.
Esthetics:
Mathematical correctness is much more aesthetic than its alternatives.
Discussion:
∂28-Apr-89 1606 CL-Cleanup-mailer Issue: MULTIPLICATION-ZERO-ARGS
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 28 Apr 89 16:06:30 PDT
Received: from fafnir.think.com by Think.COM; Fri, 28 Apr 89 18:17:10 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 28 Apr 89 18:16:27 EDT
Received: from joplin.think.com by verdi.think.com; Fri, 28 Apr 89 18:16:22 EDT
From: Guy Steele <gls@Think.COM>
Received: by joplin.think.com; Fri, 28 Apr 89 18:16:19 EDT
Date: Fri, 28 Apr 89 18:16:19 EDT
Message-Id: <8904282216.AA05993@joplin.think.com>
To: cl-cleanup@sail.stanford.edu
Cc: gls@Think.COM
Subject: Issue: MULTIPLICATION-ZERO-ARGS
Issue: MULTIPLICATION-ZERO-ARGS
References: CLtl p. 199
Category: CHANGE
Edit history: Version 1 by Guy Steele 04/28/89
Problem Description:
This function is not well-defined for sets of arguments
that include the number zero.
Proposal (MULTIPLICATION-ZERO-ARGS:NOT-ALLOWED):
Integer arguments to * must be non-zero.
Test Case:
(* 1 0) would be an error instead of having the value 0.
Rationale:
Having the product of a set of integers be less than
the product of a proper subset of that set
violates monotonicity. For example, monotonicity is violated by
(* 6 0) < (* 6) and (* 0) < (*).
The multiset of prime factors of a product is the union of the
multisets of prime factors of the numbers being multiplied.
Increasing the multiset of prime factors that contribute to the
result should only be able to increase the value of result.
What the first example is saying is that the multiset of factors
of 6 has two elements {2, 3} but the product of both 6 and 0
does not. This is patently ridiculous. Any reasoning that says that
0 is the product of 6 & 0 would also say that 0 is the product of 6 alone,
since 0 has all the prime factors that 6 does and is the smallest such number.
Furthermore, it would say that 0 is the result of the multiplication operation
on any set of arguments at all. Although this would be mathematically
consistent, it would not make multiplication a very useful operator.
The root of the problem is that it is unnatural to apply multiplication to
anything but natural numbers. Multiplication over the positive integers
forms a monoid, and over the rational numbers forms a group. Negative
numbers do not have much of an effect because they can be treated as if
they were their absolute values, with signs handled separately, but zero
really screws things up. If it is desired that zero be an allowed
argument, it should also just be ignored, (i.e passed over, the way nil in
an association list is passed over)
Current Practice:
I know of no implementations that currently implement this change.
Cost to Users:
Very slight.
Cost to Implementors:
Very slight. Should lead to a reduction in code, since most algorithms
for computing products are for positive integers anyway. (Consider what
you learned in second grade.)
Benefits:
see Esthetics.
Esthetics:
Mathematical correctness is much more aesthetic than its alternatives.
Discussion:
This is not a satire. Skona's arguments about LCM are correct, and my
arguments about multiplication are of exactly the same form. Zero really
does screw up multiplication. If it were not for addition, the value of
zero to addition, and the relationship of addition to multiplication
(especially through the distributive law), we would not put up with zero.
If you formulate multiplication in terms of unions of multisets of prime
factors (a natural and convenient representation for integers if you don't
have to do addition), then there isn't even any good representation for
zero.
But addition and zero ARE important, so we agree to extend the range of
multiplication to include zero, even though it has weird properties like
destroying the invertibility of multiplication (suddenly (/ (* A B) B)
is not always equal to A).
The same holds for GCD and LCM. Yes, their behaviors for arguments that
are zero is weird and makes no sense. But we adopt these definitions
anyway because they preserve useful identities. For example, we have the
identity
(* x (gcd y z)) = (gcd (* x y) (* x z))
If x is zero, then we had better have (gcd 0 0) = 0.
If y is zero, then we have
(* x (gcd 0 z)) = (gcd 0 (* x z))
and letting (gcd 0 a) = a is the simplest way of preserving this.
Then consider
(* u v) = (* (gcd u v) (lcm u v))
Let u be zero. Then to preserve this identity at least one of
(gcd u v) and (lcm u v) must be zero. But (gcd 0 v) = v, so if
v is not zero then (lcm 0 v) had better be zero.
See Knuth, volume 2, section 4.5.2. There you will see that he finds it
convenient to use the prime-factor representation of integers to explain
gcd and lcm (and in fact during that part of the discussion he conveniently
ignores the fact that you cannot encode zero in that representation--and
for his expository purposes it doesn't matter).
So that is why gcd and lcm behave in such strange ways: they preserve
important identities in the boundary cases. A cardinal rule of
mathematics is that consistency is more important than making sense.
(In fact, consistency is the *definition* of making sense.)
So I argue that, whatever we do, we should treat GCD/LCM and multiplication
on integers in exactly the same way. Either all accept arguments that
are zero, or none do.
∂03-May-89 1653 CL-Cleanup-mailer [chapman%aitg.DEC@decwrl.dec.com: question @ SUBTYPEP-TOO-VAGUE]
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 May 89 16:53:46 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 03 MAY 89 16:51:25 PDT
Date: 3 May 89 16:51 PDT
From: masinter.pa@Xerox.COM
Subject: [chapman%aitg.DEC@decwrl.dec.com: question @ SUBTYPEP-TOO-VAGUE]
To: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <890503-165125-11110@Xerox>
My record says that we passed version 4 at the January meeting, Guy
produced version 5 in March, but that we didn't discuss version 5, postpone
version 5, or otherwise deal with version 5 at the March meeting. I think
this one fell between the cracks... right?
----- Begin Forwarded Messages -----
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 May 89 13:08
To: @masinter@decwrl.dec.com
Subject: question @ SUBTYPEP-TOO-VAGUE
LM,
The last version I got of SUBTYPEP-TOO-VAGUE reads like it is
Version 5, but doesn't have Version 5 in the header. That's no
big deal, but since it has some big changes from Version 4, I
wondered if what I got was just a review copy or a final draft?
The reason you're getting this question (vs. KMP) is that your
name appeared twice and last in the revision list.
----- End Forwarded Messages -----
∂04-May-89 0922 CL-Cleanup-mailer Issue: SETF-MULTIPLE-STORE-VARIABLE
Received: from arisia.Xerox.COM by SAIL.Stanford.EDU with TCP; 4 May 89 09:22:39 PDT
Received: from layla.parc.Xerox.COM by arisia.Xerox.COM with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA01288; Thu, 4 May 89 09:21:02 -0700
Reply-To: <rao@arisia.Xerox.COM>
Received: by layla. (4.0/SMI-4.0)
id AA05410; Thu, 4 May 89 09:21:58 PDT
Date: Thu, 4 May 89 09:21:58 PDT
From: Ramana Rao <rao@arisia.Xerox.COM>
Message-Id: <8905041621.AA05410@layla.>
To: cl-cleanup@sail.stanford.edu
Cc: Rao@arisia.Xerox.COM, pavel.pa@Xerox.COM, gregor@arisia.Xerox.COM,
masinter.pa@arisia.Xerox.COM
Subject: Issue: SETF-MULTIPLE-STORE-VARIABLE
This message is to encourage the cleanup committee to get to and accept this
proposal and to bring up a related issue having to do with setf generic
functions in CLOS.
The case covered by the proposal is real (or at least exactly what I want to).
I have a rectangle object that has accessors for retrieving the corner points
and the extent that return two multiple values. A motivation for doing it this
way versus with structured objects is to please users that are particularly
concerned about consing new structures. So both types of methods are provided.
(I hacked a version of setf that allows setf of these accessors.)
Example:
(defmethod rectangle-min-point ((rect rectangle))
...
(make-point min-x min-y))
(defmethod rectangle-min-point* ((rect rectangle))
...
(values min-x min-y))
(defmethod (setf* rectangle-min-point*) (min-x min-y (rect rectangle))
---
)
The related issue has to do with CLOS. How does the setf generic function know
how many store values to expect? This may be a problem with having recombined
the store varables into a single argument list.
Example:
Alternatives Solutions in order of preferrence:
1) Change syntax of methods on setf generic function.
(defmethod (setf rectangle-min-point*) (min-x min-y) ((rect rectangle))
---
)
2) Extend defgeneric to allow indicating the number of store variables expected
by the setf generic function.
3) Require user to generate setf expander using some provided macro.
(def-generic-setf rectangle-min-point* 2)
Or the following allows catching some errors at setf expansion.
(def-generic-setf rectangle-min-point* (rect) (min-x min-y))
(defmethod (setf rectangle-min-point*) (min-x min-y (rect rectangle))
---
)
∂04-May-89 1244 CL-Cleanup-mailer [chapman%aitg.DEC@decwrl.dec.com: question @ SUBTYPEP-TOO-VAGUE]
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 May 89 12:44:36 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 589809; 4 May 89 13:49:40 EDT
Date: Thu, 4 May 89 13:49 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: [chapman%aitg.DEC@decwrl.dec.com: question @ SUBTYPEP-TOO-VAGUE]
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <890503-165125-11110@Xerox>
Message-ID: <19890504174937.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 3 May 89 16:51 PDT
From: masinter.pa@Xerox.COM
My record says that we passed version 4 at the January meeting, Guy
produced version 5 in March, but that we didn't discuss version 5, postpone
version 5, or otherwise deal with version 5 at the March meeting. I think
this one fell between the cracks... right?
My records are consistent with that. I never studied this issue really
carefully but version 5 was okay with me, more or less. It's still a bit
bogus because an implementation could define all type specifiers as
expansions into SATISFIES, in which case SUBTYPEP could return NIL NIL
always. I suspect the proposal was intended to rule that out, but the
actual words that it says fail to rule that out.
From: chapman%aitg.DEC@decwrl.dec.com
The last version I got of SUBTYPEP-TOO-VAGUE reads like it is
Version 5, but doesn't have Version 5 in the header. That's no
big deal, but since it has some big changes from Version 4, I
wondered if what I got was just a review copy or a final draft?
The reason you're getting this question (vs. KMP) is that your
name appeared twice and last in the revision list.
Here is a better version of version 5 that I found in our archives:
Date: Wed, 15 Mar 89 17:44:14 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903152244.AA03741@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Subject: [gls: Issue SUBTYPEP-TOO-VAGUE, version 5]
[I forgot to update the edit history. Here is corrected copy.]
Date: Wed, 15 Mar 89 17:41:16 EST
From: Guy Steele <gls>
To: cl-cleanup@sail.stanford.edu
Subject: Issue SUBTYPEP-TOO-VAGUE, version 5
Cc: gls
This is a proposed amendment to version 4 passed in January 1989 at Kauai.
Issue: SUBTYPEP-TOO-VAGUE
References: CLtL p. 72-73
Category: CLARIFICATION
Edit History: Version 1, 11 Jul 1988 (Sandra Loosemore)
Version 2, 19 Jul 1988 (Sandra Loosemore)
Version 3, 6-Oct-88 (Masinter)
Version 4, 7-Oct-88 (Masinter, per Moon's comments)
Version 5, 15-Mar-89 Steele
Problem Description:
[From version 4]
The description of SUBTYPEP allows it to return a second value of NIL
when the relationship between the two types cannot be determined. In
some cases this is a reasonable thing to do because it is impossible
to tell (if the SATISFIES type specifier is involved), and in other
cases the relationships between types are not well-defined (for
example, the VALUES type specifier or the list form of the FUNCTION
type specifier).
Some implementations, however, have apparently interpreted this to
mean that it is permissible for SUBTYPEP to "give up" and return a
second value of NIL in some cases where it actually would be possible
to determine the relationship. This makes it difficult to depend on
subtype relationships in portable code.
[Addition for version 5]
There are two problems with version 4. First is that of the first three
bulleted points in the version 4 proposal:
* Clarify that SUBTYPEP will return a second value of NIL
only when either of the type specifiers involves the SATISFIES, NOT,
AND, OR, MEMBER. SUBTYPEP will not return a second
value of NIL when both arguments involve only the words in Table 4-1, or
names of DEFSTRUCT- or DEFCLASS-defined types, or user-defined deftypes
that expand into only those words and/or names.
* SUBTYPEP should signal an error when handed (for either argument)
a type specifier that involves VALUES or the list form of the FUNCTION
type.
* SUBTYPEP must always return values T T in the case where the two
type specifiers (or their expansions) are EQUAL.
any two have significant overlap, and indeed all three can overlap;
version 4 contained no indication of how this conflict should be resolved.
Second is that version 4 calls for SUBTYPEP to signal an error (at least at
high safety)even when the arguments are valid type specifiers, but this can
make it harder to use SUBTYPEP. These are cases that returning NIL NIL
was supposed to cover.
This version replaces the three bulleted points above with a single point
and some observations about its consequences. This version eliminates
the requirement to signal an error.
Proposal: SUBTYPEP-TOO-VAGUE:CLARIFY-MORE
A type specifier "involves" a word like SATISFIES, MEMBER, NOT, etc.
if it either contains it directly or as the result of expansion of a
DEFTYPE defined type specifier.
* Clarify that SUBTYPEP is permitted to return NIL NIL only when
at least one argument involves SATISFIES, AND, OR, NOT, MEMBER,
VALUES, or the list form of FUNCTION.
Note that one consequence of this is that if neither argument
involves any of these type specifiers, then SUBTYPEP is obliged
to determine the relationship accurately. In particular, SUBTYPEP
must return T T if the arguments are EQUAL and do not involve
any of the above-stated type specifiers.
* Clarify that the relationships between types reflected by SUBTYPEP
are those specific to the particular implementation. For example, if
an implementation supports only a single type of floating-point numbers,
in that implementation (SUBTYPEP 'FLOAT 'LONG-FLOAT) would return T T
(since the two types would be identical).
Rationale:
Specifying the behavior of SUBTYPEP makes it more useful. Otherwise,
programs cannot rely on any more than NIL NIL as return values.
It is generally conceded that it is impossible to determine the
relationships between types defined with the SATISFIES specifier.
MEMBER, AND, OR, and NOT are messy to deal with.
Current Practice:
The implementation of SUBTYPEP in (the original) HPCL does not try to
expand type specifiers defined with DEFTYPE and does not recognize
EQUAL type specifiers as being equivalent. Most other implementations
appear to be substantially in conformance with the proposal.
Cost to implementors:
Some implementations will have to rewrite and/or extend parts of SUBTYPEP.
Cost to users:
Its hard to imagine a portable program that depends heavily
on SUBTYPEP. This proposal does not require any implementation
to "handle" fewer cases of SUBTYPEP.
Benefits:
An area of confusion in the language is cleared up. Usages of SUBTYPEP
will be more portable.
Discussion:
The handling of FLOAT and SINGLE-FLOAT appeared to be the
consensus from a discussion on the common-lisp mailing list some
time ago.
It would not be too onerous to require implementations to handle
the cases where one but not the other type specifier involves
OR, AND, NOT or MEMBER, but the specification becomes
cumbersome.
A related issue is clarifying what kinds of type specifiers must be
recognized by functions such as MAKE-SEQUENCE and COERCE. For example,
HPCL complains that (SIMPLE-ARRAY (UNSIGNED-BYTE *) (*)) is not a valid
sequence type when passed to MAKE-SEQUENCE, although SUBTYPEP does
recognize it to be a subtype of SEQUENCE. Should this proposal be
extended to deal with these issues, or is another proposal in order?
The rules for comparing the various type specifiers (such as ARRAY)
need to be spelled out in detail.
∂04-May-89 1251 CL-Cleanup-mailer Issue: SETF-MULTIPLE-STORE-VARIABLE
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 May 89 12:51:39 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 589900; 4 May 89 15:52:19 EDT
Date: Thu, 4 May 89 15:52 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SETF-MULTIPLE-STORE-VARIABLE
To: rao@arisia.Xerox.COM
cc: cl-cleanup@sail.stanford.edu, pavel.pa@Xerox.COM, gregor@arisia.Xerox.COM,
masinter.pa@arisia.Xerox.COM
In-Reply-To: <8905041621.AA05410@layla.>
Message-ID: <19890504195216.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Thu, 4 May 89 09:21:58 PDT
From: Ramana Rao <rao@arisia.Xerox.COM>
This message is to encourage the cleanup committee to get to and accept this
proposal
We'd better! June?
and to bring up a related issue having to do with setf generic functions in CLOS.
setf generic functions, like the short form of defsetf, only work for storing single
values. To store multiple values you need to use the long form of defsetf or
define-setf-method. I don't think it's at all hard to make a macro that expands
into a defmethod and a defsetf. It's probably not worth trying to change the
syntax of defmethod to be that macro (I think we already considered that a couple
years ago and uncovered some problems).
∂23-May-89 1013 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-CASE (version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 23 May 89 10:13:09 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 599388; 23 May 89 13:14:50 EDT
Date: Tue, 23 May 89 13:19 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-COMPONENT-CASE (version 4)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19890523171914.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
This issue is on the agenda for the June X3J13 meeting. KMP and I
have prepared a revised writeup which we think is ready for release.
I'd like to distribute this to X3J13 as soon as discussion, if any,
in the cleanup subcommittee is completed.
Issue: PATHNAME-COMPONENT-CASE
References: Pathnames (pp410-413),
MAKE-PATHNAME (p416),
PATHNAME-HOST (p417),
PATHNAME-DEVICE (p417),
PATHNAME-DIRECTORY (p417),
PATHNAME-NAME (p417),
PATHNAME-TYPE (p417)
Related-issues: PATHNAME-WILD-TRANSLATE
Category: CHANGE
Edit history: 1-Jul-88, Version 1 by Pitman
22-Mar-89, Version 2 by Moon, update and rewrite
9-May-89, Version 3 by Moon, remove alternate proposals
9-May-89, Version 4 by Moon, respond to discussion with KMP
Problem Description:
Issues of alphabetic case in pathnames are a major source of problems.
In some file systems, the customary case is lowercase, in some uppercase,
in some mixed. In some file systems, case matters, in others it does
not.
There are two kinds of pathname case portability problems: moving
programs from one Common Lisp to another, and moving pathname component
values from one file system to another. To solve the first problem, all
Common Lisp implementations that support a particular file system must
use compatible representations for pathname component values. To solve
the second problem, there must be a common representation for the least
common denominator pathname component values that exist on all
interesting file systems.
This desire for a common representation directly conflicts with the
desire among programmers who only use one file system to work with the
local conventions and not think about issues of porting to other file
systems. The common representation cannot be the same as every local
convention, since they vary.
In the current anarchy of pathname component case conventions:
(NAMESTRING (MAKE-PATHNAME :NAME "FOO" :TYPE "LISP"))
will produce foo.lisp in some Unix Common Lisp implementations
and will produce FOO.LISP in other Unix Common Lisp implementations.
(NAMESTRING (MAKE-PATHNAME :NAME "foo" :TYPE "lisp"))
will produce FOO.LISP in some Tops-20 Common Lisp implementations
and will produce "↑Vf↑Vo↑Vo.↑Vl↑Vi↑Vs↑Vp"in other Tops-20 Common
Lisp implementations.
Problems like this make it difficult to use MAKE-PATHNAME for much of
anything without corrective (non-portable) code.
Other problems occur in merging because doing
(NAMESTRING (MERGE-PATHNAMES (MAKE-PATHNAME :HOST "MY-TOPS-20" :NAME "FOO")
(PARSE-NAMESTRING "MY-UNIX:x.lisp")))
should probably return "MY-TOPS-20:FOO.LISP" but in fact might return
"MY-TOPS-20:FOO.↑Vl↑Vi↑Vs↑Vp" in some implementations.
Problems like this make it difficult to use any merging primitives for
much of anything without corrective (non-portable) code.
Proposal (PATHNAME-COMPONENT-CASE:KEYWORD-ARGUMENT):
Add a keyword argument :CASE to MAKE-PATHNAME, PATHNAME-HOST,
PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, and PATHNAME-TYPE.
The possible values for the argument are :COMMON and :LOCAL.
:LOCAL means strings input to MAKE-PATHNAME or output by PATHNAME-xxx
follow the local file system's conventions for alphabetic case.
:COMMON means those strings follow this common convention:
- all uppercase means to use a file system's customary case.
- all lowercase means to use the opposite of the customary case.
- mixed case represents itself.
The second and third bullets exist so that translation from local to
common and back to local is information-preserving.
The default is :COMMON.
Namestrings always use local file system case conventions.
MERGE-PATHNAMES and TRANSLATE-WILD-PATHNAME map customary case in the
input pathnames into customary case in the output pathname.
Implications of the proposal:
Unix is case-sensitive and prefers lowercase, so it translates between
common and local by inverting the case of non-mixed-case strings.
Tops-20 is case-sensitive and prefers uppercase, so it uses identical
representations for common and local.
VAX/VMS is upper-case-only, so it translates common to local by upcasing,
and translates local to common with no change.
Macintosh is case-insensitive and prefers lowercase, so it translates
between common and local by inverting the case of non-mixed-case strings,
and ignores case in EQUAL of two pathnames.
Test Case/Examples:
Under PATHNAME-COMPONENT-CASE:KEYWORD-ARGUMENT:
(PATHNAME-NAME (PARSE-NAMESTRING "MY-UNIX:/me/foo.lisp")
:CASE :COMMON) => "FOO"
(PATHNAME-NAME (PARSE-NAMESTRING "MY-TOPS-20:<ME>FOO.LISP")
:CASE :COMMON) => "FOO"
(PATHNAME-NAME (PARSE-NAMESTRING "MY-UNIX:/me/foo.lisp")
:CASE :LOCAL) => "foo"
(PATHNAME-NAME (PARSE-NAMESTRING "MY-TOPS-20:<ME>FOO.LISP")
:CASE :LOCAL) => "FOO"
(PATHNAME-NAME (PARSE-NAMESTRING "MY-UNIX:/me/TeX.lisp")
:CASE :COMMON) => "TeX"
(PATHNAME-NAME (PARSE-NAMESTRING "MY-UNIX:/me/TeX.lisp")
:CASE :LOCAL) => "TeX"
(NAMESTRING (MAKE-PATHNAME :HOST "MY-UNIX" :NAME "FOO"
:CASE :COMMON) => "MY-UNIX:foo"
Rationale:
This does not solve the whole pathname problem, but it does improve
the situation for a clearly defined set of very common problems.
Together with the other pathname proposals, the behavior of pathnames
should be sufficiently consistent across Common Lisp implementations
and across file systems to allow portability of pathname-manipulating
programs.
Upper case is chosen as the common case for no better reason than
consistency with Lisp symbols.
The :CASE keyword argument provides access to both common and local
conventions without introducing any new functions. The default
convention is the common one, assuming that most programs are fully
portable and therefore :COMMON will be more frequently used.
Current Practice:
There are no known implementations of exactly what is proposed.
Symbolics Genera uses common case normally, and provides a way to
access the local case (called "raw") that in practice is rarely used.
Symbolics Genera's own file system uses lower case as the customary
case, but transparent network access is available to file systems
using all known case conventions.
Several Common Lisp implementations behave as if :CASE :LOCAL was
specified (but accept no :CASE argument).
Cost to Implementors:
The :CASE feature is easily added, but some implementations may have
to change the default behavior when :CASE is not specified. No
implementation need change its internal representation, nor the way
pathnames print, just the interface functions listed above.
Cost to Users:
Technically, this change is upward compatible.
In fact, since the existing CLtL spec is so poor, nearly everyone relies
heavily on implementation-specific behavior since there is little other
choice. As such, any change is almost certain to break lots of programs,
in usually superficial but nevertheless important ways. However, if we
really make the pathname facility more portable, the user community may
be willing to bear the consequences of these changes.
Cost of Non-Adoption:
We would be contributing to the perpetuation of the existing fiasco of a
pathname system.
Performance Impact:
None.
Benefits:
One step closer to a usable pathname system.
Aesthetics:
Anything that simplifies the user model of pathnames is an improvement.
Discussion:
Some people would rather use lowercase as the common case. The
decision is essentially arbitrary. Everywhere else in Common Lisp
where case matters, uppercase was chosen.
It has been proposed that the Common Lisp specification should include
specifications of the exact behavior of pathnames for several popular
operating systems, so that multiple implementations for those
operating systems would be compatible with each other. This proposal
does that for alphabetic case.
Some people want the default for :CASE to be :LOCAL instead of :COMMON.
See Rationale.
There should probably be a remark somewhere that says that portable
programs shouldn't expect to be able to create and/or access distinct
files whose pathname components differ only in case.
∂23-May-89 1014 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-VALUE (version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 23 May 89 10:13:57 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 599391; 23 May 89 13:15:46 EDT
Date: Tue, 23 May 89 13:20 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-COMPONENT-VALUE (version 2)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19890523172011.4.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
This issue is on the agenda for the June X3J13 meeting. KMP and I
have prepared a revised writeup which we think is ready for release.
I'd like to distribute this to X3J13 as soon as discussion, if any,
in the cleanup subcommittee is completed.
Issue: PATHNAME-COMPONENT-VALUE
Related Issues:PATHNAME-CANONICAL-TYPE,
PATHNAME-SUBDIRECTORY-LIST,
PATHNAME-UNSPECIFIC-COMPONENT,
PATHNAME-WILD
References: CLtL pp.410-3
Category: CLARIFICATION and CHANGE
Edit history: Version 1, 20-Mar-89, by Moon
Version 2, 9-May-89, by Moon (rewrite based on mail)
Problem description:
CLtL is overly restrictive on the possible values for pathname components.
These restrictions are described in a funny way that makes it unclear
whether they are requirements, guidelines, or just an example.
The restrictions are not all written down in one place, but they appear
to be as follows:
Host nil, :wild, string, or list of strings
Device nil, :wild, string, or something else ("structured")
Directory nil, :wild, string, or something else ("structured")
Name nil, :wild, string, or something else ("structured")
Type nil, :wild, or string
Version nil, :wild, :newest, positive integer, implementation
dependent symbol, or implementation-dependent integer
less than or equal to zero. Suggestions include :oldest,
:previous, :installed, 0, and -1.
PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN allowed implementations to
allow any component to be :UNSPECIFIC. This has been voted in.
PATHNAME-SUBDIRECTORY-LIST proposes a list of strings and keyword
symbols for the directory component.
PATHNAME-CANONICAL-TYPE proposes some new operations but does not
change the possible values of the type component.
PATHNAME-WILD proposes a portable way to test for implementation
dependent component values that indicate wildcard matching. It
does not change the possible values of any component.
Proposal (PATHNAME-COMPONENT-VALUE:SPECIFY):
The points of the proposal have been numbered/lettered to facilitate
discussion of individual points.
0. Pathname component value strings never contain the punctuation
characters that are used to separate pathname fields (e.g. slashes and
dots in Unix). Punctuation characters appear only in namestrings.
Characters used as punctuation can appear in pathname component values
with a non-punctuation meaning if the file system allows it (e.g. a Unix
file name that begins with a dot).
When examining pathname components, conforming programs must be prepared
to encounter any of the following values:
1. Any component can be NIL, which means the component has not
been specified.
2. Any component can be :UNSPECIFIC, which means the component has
no meaning in this particular pathname.
3. The device, directory, name, and type can be strings.
4. The host can be any object, at the discretion of the implementation.
5. The directory can be a list of strings and symbols as detailed in
PATHNAME-SUBDIRECTORY-LIST (this assumes that it passes.)
6. The version can be any symbol or any integer. The symbol :NEWEST
refers to the largest version number that already exists in the file
system when reading, overwriting, appending, superseding, or directory
listing an existing file, and refers to the smallest version number
greater than any existing version number when creating a new file.
Other symbols and integers have implementation-defined meaning.
It is suggested, but not required, that implementations use positive
integers starting at 1 as version numbers, recognize the symbol :OLDEST
to designate the smallest existing version number, and use keyword
symbols for other special versions.
Wildcard pathnames can be used with DIRECTORY but not with OPEN, and
return true from WILD-PATHNAME-P (if issue PATHNAME-WILD passes). When
examining wildcard components of a wildcard pathname, conforming programs
must be prepared to encounter any of the following additional values
in any component or any element of a list that is the directory component:
7. :WILD, which matches anything.
8. A string containing implementation-dependent special wildcard
characters.
9. Any object, representing an implementation-dependent wildcard
pattern.
When constructing a pathname from components, conforming programs
must follow these rules:
a. Any component can be NIL. NIL in the host may mean a default host
rather than an actual NIL in some implementations.
b. The host, device, directory, name, and type can be strings. There
are implementation-dependent limits on the number and type of
characters in these strings.
c. The directory can be a list of strings and symbols as detailed in
PATHNAME-SUBDIRECTORY-LIST (this assumes that it passes.) There are
implementation-dependent limits on the list's length and contents.
d. The version can be :NEWEST.
e. Any component can be taken from the corresponding component
of another pathname. When the two pathnames are for different
file systems (in implementations that support multiple file
systems), an appropriate translation occurs. If no meaningful
translation is possible, an error is signalled. The definitions
of "appropriate" and "meaningful" are implementation-dependent.
f. When constructing a wildcard pathname, the name, type, or version
can be :WILD, which matches anything.
g. An implementation might support other values for some components,
but a portable program cannot use those values. A conforming program
can use implementation-dependent values but this can make it
non-portable, for example, it might work only with Unix file systems.
Consequences:
The changes relative to CLtL plus PATHNAME-UNSPECIFIC-COMPONENT
are as follows:
The removal of punctuation characters during parsing is specified.
"Structured" components are disallowed in non-wildcard pathnames,
except for the specific structuring of directories specified
in issue PATHNAME-SUBDIRECTORY-LIST.
"Structured" hosts are allowed, a generalization of CLtL's list
of strings.
The type and version can be "structured" in wildcard pathnames.
The difference between what component values a program can depend
on being able to use, versus what component values a program must
be prepared to encounter, is clarified.
The implementation-dependent variations are identified explicitly.
Rationale:
This should make it easier to write portable programs that deal with
pathnames and make it easier for implementors by clarifying the
framework into which they must fit. Also it should make it easier
to write the Common Lisp language specification by resolving some
things that were unclear about the status quo.
Adding "structured" hosts conforms to current practice.
Substituting a default host for NIL conforms to current practice
in implementations that require all pathnames to have a specific host.
Confining "structured" devices and names to wildcard pathnames, and
replacing "structured" directories with an explicit specification of
the form of the directory value, should improve portability without causing
any harm.
:WILD is only required to be supported in the name, type, or version,
which are the easiest to implement and the most useful in applications.
Current practice:
All versions of Symbolics Genera violate CLtL in the matter of hosts,
since it uses standard-objects as the host component. Genera deviates
slightly from PATHNAME-SUBDIRECTORY-LIST, but otherwise conforms to
PATHNAME-COMPONENT-VALUE:SPECIFY.
Other implementations were not surveyed.
This proposal assumes that no current or planned implementation
uses "structured" names except possibly for wildcards.
Cost to Implementors:
Most implementations already conform, except for the changes required
by PATHNAME-UNSPECIFIC-COMPONENT and PATHNAME-SUBDIRECTORY-LIST, so
the cost of this proposal itself should be minimal. It is conceivable
that an implementation may exist that has to change its pathname
representation, for example one that uses numbers as "structured" devices.
Some implementations may have to change their treatment of punctuation
characters.
Cost to Users:
None.
Cost of non-adoption:
Pathnames will continue to be a poorly specified part of the language.
Performance impact:
None of any significance.
Benefits/Esthetics:
The boundary between the specified behavior of pathnames and the
implementation-dependent behavior of pathnames will be more clear.
Discussion:
None.
∂23-May-89 1015 CL-Cleanup-mailer Issue: PATHNAME-LOGICAL (version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 23 May 89 10:15:38 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 599393; 23 May 89 13:17:22 EDT
Date: Tue, 23 May 89 13:21 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-LOGICAL (version 2)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19890523172147.5.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
This issue is on the agenda for the June X3J13 meeting. This issue has
not been written up before. With KMP's help I have prepared a writeup
which we think is ready for release. I'd like to distribute this to
X3J13 as soon as discussion, if any, in the cleanup subcommittee is
completed.
Issue: PATHNAME-LOGICAL
References: Pathnames (pp410-413)
OPEN (p.418), WITH-OPEN-FILE (p.422), RENAME-FILE (p.423),
DELETE-FILE (p.424), PROBE-FILE (p.424),
FILE-WRITE-DATE (p.424), FILE-AUTHOR (p.424), LOAD (p.426),
COMPILE-FILE (p.439), DIRECTORY (p.427), PATHNAME (p.413),
TRUENAME (p.413), MERGE-PATHNAMES (p.415),
MAKE-PATHNAME (p.416), and PARSE-NAMESTRING (p.414).
Related issues: PATHNAME-CANONICAL-TYPE, PATHNAME-COMPONENT-VALUES,
PATHNAME-SUBDIRECTORY-LIST, and PATHNAME-WILD
Category: ADDITION
Edit history: Version 1, 11-May-89, by Moon
Version 2, 18-May-89, by Moon
Problem description:
Pathname values are not portable, but they are sometimes part of a
program, for example the names of files containing the program and the
data used by the program. Moving large programs between sites would
be easier if pathname values did not have to be translated.
Pathname values are nonportable because not all Common Lisp
implementations use the same operating system and file name syntax varies
widely among operating systems. In addition, corresponding files at two
different sites may have different names even when the operating system
is the same; for example, they may be on different directories or
different devices.
The issue of portable pathname values is separate from the issues of
portable pathname operations. See the related issues listed above.
For inter-issue interactions, see the discussion section below.
Proposal (PATHNAME-LOGICAL:ADD):
Define a "logical" file system that looks the same at every site. This
file system is implemented by translating each logical pathname into a
physical pathname on a real file system. The logical pathnames are the
same at all sites, but the translation rules are different at each site,
thus the physical pathnames can be different at each site.
The syntax of a logical pathname namestring is as follows:
host ":" { directory ";" }* [ name ] [ "." type [ "." version ]]
Terminology:
A word consists of one to twelve uppercase letters, digits, and hyphens.
Lowercase letters are translated to uppercase. The consequences of using
other characters, or more than twelve characters, are unspecified. A
wildcard word is "*" (:WILD), which matches anything, or a word with one
or more asterisk characters inserted into it, with no two asterisks
adjacent; each asterisk matches a sequence of zero or more characters.
The maximum number of non-asterisk characters in a wildcard word is 12.
The host is a word that has been defined as a logical pathname host by
using DEFINE-LOGICAL-PATHNAME-TRANSLATIONS.
There is no device, so the device component of a logical pathname is
always :UNSPECIFIC. No other component can be :UNSPECIFIC.
Each directory is a word, a wildcard word, or "**" (:WILD-INFERIORS).
There are no relative directories.
The name is a word or a wildcard word.
The type is a word or a wildcard word.
The version is a positive decimal integer of one to six digits or
"NEWEST" (:NEWEST) or "*" (:WILD). The letters in "NEWEST" can be in
either alphabetic case. The consequences of using anything else as a
version are unspecified.
Some real file systems do not have versions. Logical pathname
translation to such a file system ignores the version. This implies that
a program cannot rely on being able to store more than one version of a
file named by a logical pathname.
The type of a logical pathname for a Common Lisp source file is "LISP".
This should be translated into whatever type is appropriate in a physical
pathname.
The logical pathname host name "SYS" is reserved for the implementation.
The existence and meaning of SYS: logical pathnames is
implementation-defined.
The functions OPEN (and WITH-OPEN-FILE), RENAME-FILE, DELETE-FILE,
PROBE-FILE, FILE-WRITE-DATE, FILE-AUTHOR, LOAD, COMPILE-FILE, DIRECTORY,
and TRUENAME accept logical pathnames and translate them into physical
pathnames. PATHNAME of a stream created by OPEN of a logical pathname is
a logical pathname. TRUENAME, PROBE-FILE, and DIRECTORY never return
logical pathnames. RENAME-FILE with a logical pathname as the second
argument returns a logical pathname as the first value. MERGE-PATHNAMES
returns a logical pathname if and only if its first argument is a logical
pathname or its first argument does not specify a host and the default
host is logical. MAKE-PATHNAME returns a logical pathname if and only if
the host is logical. PARSE-NAMESTRING returns a logical pathname if and
only if the string begins with a logical pathname host name (defined by
using DEFINE-LOGICAL-PATHNAME-TRANSLATIONS) and a colon, or the string
does not specify a host and the default host is logical.
Add these defined names to Common Lisp in support of logical pathnames:
LOGICAL-PATHNAME [Class]
LOGICAL-PATHNAME is a subclass of PATHNAME.
TRANSLATE-LOGICAL-PATHNAME pathname [Function]
Translate a logical pathname to the corresponding physical pathname.
The pathname argument is first coerced to a pathname. If it is not a
pathname, string, or file stream an error of type TYPE-ERROR is
signalled. If the coerced argument is a logical pathname, the first
matching translation (according to PATHNAME-MATCH-P) of the logical
pathname host is applied, using TRANSLATE-PATHNAME with the reversible
argument true, and three values are returned:
1. The physical pathname
2. The from-wildcard of the translation
3. The to-wildcard of the translation
If no translation matches, an error of type FILE-ERROR is signalled.
If the coerced argument is a physical pathname, it is returned as all
three values.
DEFINE-LOGICAL-PATHNAME-TRANSLATIONS host translations &key [Function]
Define a logical pathname host named <host> (a string or a symbol which
is coerced to a string). <translations> is a list of translations.
Each translation is a list of from-wildcard and to-wildcard.
From-wildcard must be a logical pathname or a string coercible to a
logical pathname. To-wildcard must be a physical pathname or a string
coercible to a physical pathname. Translations are searched in the
order listed, so more specific from-wildcards must precede more general
ones.
The specified translations might be modified or augmented in an
implementation-dependent fashion, typically to provide translation of
file types to local naming conventions, to accomodate physical file
systems with limited length names, or to deal with special character
requirements such as translating hyphens to underscores or uppercase
letters to lowercase. These modifications are reflected in the second
and third values returned by TRANSLATE-LOGICAL-PATHNAME in such a way
that TRANSLATE-PATHNAME used with them produces the same translation.
If a logical pathname host named <host> already exists, its existing
translations are replaced.
There are no keyword arguments specified by this standard, but any
implementation extensions are provided as keyword arguments or as
translations with more than two elements.
LOAD-LOGICAL-PATHNAME-TRANSLATIONS host [Function]
If a logical pathname host named <host> (a string or a symbol which is
coerced to a string) is already defined, return NIL. Otherwise, search
for a logical pathname host definition in an implementation defined
manner. If none is found, signal an error. If a definition is found,
install it and return T.
The search used by LOAD-LOGICAL-PATHNAME-TRANSLATIONS should be
documented, as logical pathname definitions will be created by users,
not only by Lisp implementors.
COMPILE-FILE-PATHNAME pathname &key :output-file [Function]
Returns the pathname that COMPILE-FILE would write into, if given
the same arguments.
Examples:
;A simple, and typical, example
(define-logical-pathname-translations "FOO"
'(("FOO:**;*.*.*" "MY-LISPM:>library>foo>**>")))
;A more complex example
(define-logical-pathname-translations "PROG"
'(("PROG:RELEASED;*.*.*" "MY-UNIX:/sys/bin/my-prog/")
("PROG:RELEASED;*;*.*.*" "MY-UNIX:/sys/bin/my-prog/*/")
("PROG:EXPERIMENTAL;*.*.*" "MY-UNIX:/usr/Joe/development/prog/")
("PROG:EXPERIMENTAL;DOCUMENTATION;*.*.*"
"MY-VAX:SYS$DISK:[JOE.DOC]")
("PROG:EXPERIMENTAL;*;*.*.*" "MY-UNIX:/usr/Joe/development/prog/*/")
("PROG:MAIL;**;*.MAIL" "MY-VAX:SYS$DISK:[JOE.MAIL.PROG...]*.MBX")))
;This function is like DIRECTORY, but if its argument is a logical
;pathname it returns logical pathnames in the results. If its
;argument is a physical pathname, it is the same as DIRECTORY.
(defun logical-directory (pathname)
(multiple-value-bind (physical from-wildcard to-wildcard)
(translate-logical-pathname pathname)
(map 'list #'(lambda (truename)
(translate-pathname truename to-wildcard
from-wildcard t))
(directory physical))))
Rationale:
Large programs can be moved between sites without changing any pathnames,
provided all pathnames used are logical. A portable system construction
tool can be created that operates on programs defined as sets of files.
Logical pathname syntax was chosen to be easily translated into most
popular file systems, while still being powerful enough for storing large
programs. Logical pathnames have least-common-denominator capabilities.
Although they have hierarchical directories, versions, and a medium sized
maximum name length, they can be mapped onto a less capable real file
file system by translating each directory that is used into a flat
directory name, treating all versions as :newest, and/or using special
implementation-dependent translation rules to shorten long names.
More advanced capabilities such as relative pathnames and a name for the
root directory were not felt to be necessary in logical pathnames. They
could be added later if a need emerges.
It is not a goal of logical pathnames to be able to represent all
possible file names. Their goal is rather to represent just enough file
names to be useful for storing software. Real pathnames, in contrast,
need to provide a uniform interface to all possible file names, including
names and naming conventions that are not under the control of Common
Lisp.
The choice of logical pathname syntax was guided by the goal of being
visually distinct from real file systems.
The numbers twelve and six are arbitrary but chosen to accomodate
both typical program file names and typical file system limitations.
File systems that are more limited can still be accomodated through
additional implementation-dependent translation as pointed out earlier.
The LOGICAL-PATHNAME class exists so that methods can distinguish
logical pathnames from regular pathnames.
The two extra values returned by TRANSLATE-LOGICAL-PATHNAME allow
for back-translation, as shown in the LOGICAL-DIRECTORY example.
Loading of logical pathname translations from a site-dependent file
allows software to be distributed using logical pathnames. The software
is supplied with logical pathnames and a sample set of translations. The
actual translations are defined by the user of the software, since the
supplier does not know the user's local file system conventions. Loading
the software uses these translations via LOAD-LOGICAL-PATHNAME-TRANSLATIONS.
The COMPILE-FILE-PATHNAME function and the specification of "LISP" as the
type of a logical pathname for a Common Lisp source file together provide
enough information about compilation for a portable system construction
tool that uses logical pathnames to work.
Current practice:
Symbolics Genera has had a similar facility for many years. It is used
extensively for software distribution by Symbolics and its customers.
The Genera facility uses the same logical pathname syntax but different
function names, and is somewhat more complicated. The extra complexity
is not necessary in the Common Lisp standard.
Symbolics Genera offers a function for translating from a physical
pathname back to a logical pathname. There are a number of problems with
this, and so it has not been proposed here. Instead
TRANSLATE-LOGICAL-PATHNAME returns enough information to allow the user
program to perform the backtranslation itself.
The Genera equivalent of LOAD-LOGICAL-PATHNAME-TRANSLATIONS looks for
a file named SYS:SITE;hostname.TRANSLATIONS.
Cost to Implementors:
This is a fairly complex facility, but its performance is unimportant
so a straightforward implementation should suffice. Most of the
complexity comes in dealing with unusual file systems, such as ones
that don't allow file names longer than eight characters.
Cost to Users:
None.
Cost of non-adoption:
Portable software construction and distribution will have to rely on
implementation-dependent kludges. Lisp software will continue to be
difficult to install.
Performance impact:
None.
Benefits:
Avoid cost of non-adoption.
Esthetics:
Improved portability of large programs.
Discussion:
Issue PATHNAME-LOGICAL fundamentally depends on issue PATHNAME-WILD.
If PATHNAME-CANONICAL-TYPE:NEW-CONCEPT passes, it will affect the
behavior of the function TRANSLATE-PATHNAME and therefore the behavior of
the function TRANSLATE-LOGICAL-PATHNAME. When a logical pathname
translation has from and to type fields that are * or omitted,
translation of the type will be guided by canonical types. If
PATHNAME-CANONICAL-TYPE:NEW-CONCEPT fails to pass, it will either have to
be done behind the scenes by TRANSLATE-PATHNAME or users will have to
write more verbose translations that individually specify the handling of
each file type.
∂23-May-89 1017 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (version 6)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 23 May 89 10:16:36 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 599395; 23 May 89 13:18:24 EDT
Date: Tue, 23 May 89 13:22 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (version 6)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19890523172251.6.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
This issue is on the agenda for the June X3J13 meeting. KMP and I
have prepared a revised writeup which we think is ready for release.
I'd like to distribute this to X3J13 as soon as discussion, if any,
in the cleanup subcommittee is completed.
Issue: PATHNAME-SUBDIRECTORY-LIST
References: Pathnames (pp410-413), MAKE-PATHNAME (p416),
PATHNAME-DIRECTORY (p417)
Related-issues: PATHNAME-COMPONENT-CASE, PATHNAME-COMPONENT-VALUE
Category: CHANGE
Edit history: 18-Jun-87, Version 1 by Ghenis.pasa@Xerox.COM
05-Jul-88, Version 2 by Pitman (major revision)
28-Dec-88, Version 3 by Pitman (merge discussion)
22-Mar-89, Version 4 by Moon (fix based on discussion)
19-May-89, Version 5 by Moon (improve based on mail)
21-May-89, Version 6 by Moon (final cleanups)
Problem Description:
It is impossible to write portable code that can produce a pathname
in a subdirectory of a hierarchical file system. This defeats much of
the purpose of the pathname abstraction.
According to CLtL, only a string is a portable value for the directory
component of a pathname. Thus in order to denote a subdirectory, the use
of punctuation characters (such as dots, slashes, or backslashes) would
be necessary. The very fact that such syntax varies from host to host
means that although the representation might be "portable", the code
using that representation is not portable.
This problem is even worse for programs running on machines on a network
that can retrieve files from multiple hosts, each using a different OS
and thus different subdirectory punctuation.
Related problems:
- In some implementations "FOO.BAR" might denote the "BAR" subdirectory
of "FOO", while in other implementations it would denote a top-level
directory, because "." is not treated as punctuation. To be safe,
portable programs must avoid all potential punctuation characters.
- Even in implementations where "." is used for subdirectories,
"FOO.BAR" may be recognized by some to mean the "BAR" subdirectory of
"FOO" and by others to mean `a seven character directory name with "."
as the fourth character.'
- In fact, CLtL does not even say whether punctuation characters are
part of the string. eg, is "foo" or "/foo" the directory component for
a unix pathname "/foo/bar.lisp". Similarly, is "[FOO]" or "FOO" the
directory component for a VMS pathname "[FOO]ME.LSP"?
PATHNAME-COMPONENT-VALUE:SPECIFY says punctuation characters are not
part of the string.
Proposal (PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION)
Remove the "structured" directory feature mentioned on CLtL p.412.
Allow the value of a pathname's directory component to be a list. The
car of the list is one of the symbols :ABSOLUTE or :RELATIVE.
Each remaining element of the list is a string or a symbol (see below).
Each string names a single level of directory structure. The strings
should contain only the directory names themselves -- no punctuation
characters.
A list whose car is the symbol :ABSOLUTE represents a directory path
starting from the root directory. The list (:ABSOLUTE) represents
the root directory. The list (:ABSOLUTE "foo" "bar" "baz") represents
the directory called "/foo/bar/baz" in Unix [except possibly for
alphabetic case -- that is the subject of a separate issue].
A list whose car is the symbol :RELATIVE represents a directory path
starting from a default directory. The list (:RELATIVE) has the same
meaning as NIL and hence is not used. The list (:RELATIVE "foo" "bar")
represents the directory named "bar" in the directory named "foo" in the
default directory.
In place of a string, at any point in the list, symbols may occur to
indicate special file notations. The following symbols have standard
meanings. Implementations are permitted to add additional objects of any
non-string type if necessary to represent features of their file systems
that cannot be represented with the standard strings and symbols.
Supplying any non-string, including any of the symbols listed below, to a
file system for which it does not make sense signals an error of type
FILE-ERROR. For example, Unix does not support :WILD-INFERIORS.
:WILD - Wildcard match of one level of directory structure.
:WILD-INFERIORS - Wildcard match of any number of directory levels.
:UP - Go upward in directory structure (semantic).
:BACK - Go upward in directory structure (syntactic).
"Syntactic" means that the action of :BACK depends only on the pathname
and not on the contents of the file system. "Semantic" means that the
action of :UP depends on the contents of the file system; to resolve
a pathname containing :UP to a pathname whose directory component
contains only :ABSOLUTE and strings requires probing the file system.
:UP differs from :BACK only in file systems that support multiple
names for directories, perhaps via symbolic links. For example,
suppose that there is a directory
(:ABSOLUTE "X" "Y" "Z")
linked to
(:ABSOLUTE "A" "B" "C")
and there also exist directories
(:ABSOLUTE "A" "B" "Q")
(:ABSOLUTE "X" "Y" "Q")
then
(:ABSOLUTE "X" "Y" "Z" :UP "Q")
designates
(:ABSOLUTE "A" "B" "Q")
while
(:ABSOLUTE "X" "Y" "Z" :BACK "Q")
designates
(:ABSOLUTE "X" "Y" "Q")
If a string is used as the value of the :DIRECTORY argument to
MAKE-PATHNAME, it should be the name of a toplevel directory and should
not contain any punctuation characters. Specifying a string, str, is
equivalent to specifying the list (:ABSOLUTE str). Specifying the symbol
:WILD is equivalent to specifying the list (:ABSOLUTE :WILD-INFERIORS),
or (:ABSOLUTE :WILD) in a file system that does not support :WILD-INFERIORS.
The PATHNAME-DIRECTORY function always returns NIL, :UNSPECIFIC, or a
list, never a string, never :WILD.
In non-hierarchical file systems, the only valid list values for the
directory component of a pathname are (:ABSOLUTE string) and
(:ABSOLUTE :WILD). :RELATIVE directories and the keywords
:WILD-INFERIORS, :UP, and :BACK are not used in non-hierarchical file
systems.
Pathname merging treats a relative directory specially. Let
<pathname> and <defaults> be the first two arguments to
MERGE-PATHNAMES. If (PATHNAME-DIRECTORY <pathname>) is a list whose
car is :RELATIVE, and (PATHNAME-DIRECTORY <defaults>) is a list, then
the merged directory is the value of
(APPEND (PATHNAME-DIRECTORY <defaults>)
(CDR ;remove :RELATIVE from the front
(PATHNAME-DIRECTORY <pathname>)))
except that if the resulting list contains a string or :WILD immediately
followed by :BACK, both of them are removed. This removal of redundant
:BACKs is repeated as many times as possible.
If (PATHNAME-DIRECTORY <defaults>) is not a list or
(PATHNAME-DIRECTORY <pathname>) is not a list whose car is :RELATIVE, the
merged directory is
(OR (PATHNAME-DIRECTORY <pathname>) (PATHNAME-DIRECTORY <defaults>))
A relative directory in the pathname argument to a function such as
OPEN is merged with *DEFAULT-PATHNAME-DEFAULTS* before accessing the
file system.
Test Cases/Examples:
(PATHNAME-DIRECTORY (PARSE-NAMESTRING "[FOO.BAR]BAZ.LSP")) ;on VMS
=> (:ABSOLUTE "FOO" "BAR")
(PATHNAME-DIRECTORY (PARSE-NAMESTRING "/foo/bar/baz.lisp")) ;on Unix
=> (:ABSOLUTE "foo" "bar")
or (:ABSOLUTE "FOO" "BAR")
If PATHNAME-COMPONENT-CASE:KEYWORD-ARGUMENT passes with a default of
:COMMON, the value is the second one shown.
(PATHNAME-DIRECTORY (PARSE-NAMESTRING "../baz.lisp")) ;on Unix
=> (:RELATIVE :UP)
(PATHNAME-DIRECTORY (PARSE-NAMESTRING "/foo/bar/../mum/baz")) ;on Unix
=> (:ABSOLUTE "foo" "bar" :UP "mum")
(PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>**>bar>baz.lisp")) ;on LispM
=> (:ABSOLUTE "FOO" :WILD-INFERIORS "BAR")
(PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>*>bar>baz.lisp")) ;on LispM
=> (:ABSOLUTE "FOO" :WILD "BAR")
Rationale:
This would allow programs to usefully deal with hierarchical file
systems, which are by far the most common file system type.
This would allow a system construction utility that organizes programs
by subdirectories to be portable to all implementations that have
hierarchical file systems.
Discussion indicated that "Implementations are permitted to add
additional objects of any non-string type if necessary to represent
features of their file systems that cannot be represented with the
standard strings and symbols" is a necessary escape hatch for things like
home directories and fancy pattern matching. Implementations should
limit their use of this loophole and use the standard keyword symbols
whenever that is possible.
Current Practice:
Symbolics Genera implements something very similar to this. The main
differences are:
- In Genera, there is no :ABSOLUTE keyword at the head of the list.
This has been shown to cause some problems in dealing with root
directories. Genera represents the root directory by a keyword
symbol (rather than a list) because the list representation
was not adequately general.
- Genera has no separate concepts of :UP and :BACK. Genera
represents Unix ".." as :UP, but deals with :UP syntactically, not
semantically.
Cost to Implementors:
In principle, nothing about the implementation needs to change except
the treatment of the directory component by MAKE-PATHNAME and
PATHNAME-DIRECTORY. The internal representation can otherwise be left
as-is if necessary.
Implementations such as Genera that already have hierarchical directory
handling will have to make an incompatible change to switch to what
is proposed here.
For implementations that choose to rationalize this representation
throughout their internals and any other implementation-specific
accessors, the cost will be necessarily higher.
Cost to Users:
None for portable programs. This change is upward compatible with CLtL.
Nonportable programs will have to be changed if they use implementation
dependent hierarchical directory handling and the implementation
removes support for that when it adds support for this proposal.
Cost of Non-Adoption:
Serious portability problems would continue to occur. Programmers would be
driven to the use of implementation-specific facilities because the need
for this is frequently impossible to ignore.
Benefits:
The serious costs of non-adoption would be avoided.
Aesthetics:
This representation of hierarchical pathnames is easy to use and quite
general. Users will probably see this as an improvement in the aesthetics.
Discussion:
This issue was raised a while back but no one was fond of the particular
proposal that was submitted. This is an attempt to revive the issue.
The original proposal, to add a :SUBDIRECTORIES component to a
pathname, was discarded because it imposed an unnatural distinction
between a toplevel directory and its subdirectories. Pitman's guess is
the the idea was to try to make it a compatible change, but since most
programmers will probably want to change from implementation-specific
primitives to portable ones anyway, that's probably not such a big
deal. Also, there could have been some programs which thought the
change was compatible and ended up ignoring important information (the
:SUBDIRECTORIES component). Pitman thought it would be better if
people just accepted the cost of an incompatible change in order to
get something really pretty as a result.
Moon doesn't like having both :UP and :BACK, but admits that some
file systems do it one way and some do it the other. He still thinks
it would be simpler not to have both.
To keep it simple, we chose not to add to this issue the functions
DIRECTORY-PATHNAME-AS-FILE and PATHNAME-AS-DIRECTORY, which convert
the name of a directory from or to the directory component of a file
inferior to that directory. This conversion is system-dependent, for
example TOPS-20 appends a type field and Unix does not. Also in some
systems the root directory has a name and in others it doesn't. Of
course these functions signal an error in non-hierarchical file
systems. Examples (for Unix, assuming #P print syntax for pathnames):
(directory-pathname-as-file #P"/usr/bin/sh") => #P"/usr/bin"
(pathname-as-directory #P"/usr/bin") => #P"/usr/bin"/
These functions have not been proposed because they are mainly useful
in conjunction with additional functions for manipulating directories
(creating, expunging, setting access control) that have not been made
available in Common Lisp.
∂23-May-89 1018 CL-Cleanup-mailer Issue: PATHNAME-WILD (version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 23 May 89 10:18:45 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 599400; 23 May 89 13:20:31 EDT
Date: Tue, 23 May 89 13:24 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-WILD (version 5)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19890523172456.7.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
This issue is on the agenda for the June X3J13 meeting. KMP and I
have prepared a revised writeup which we think is ready for release.
I'd like to distribute this to X3J13 as soon as discussion, if any,
in the cleanup subcommittee is completed.
Issue: PATHNAME-WILD
References: Pathnames (pp410-413)
Related issues: PATHNAME-LOGICAL
Category: ADDITION
Edit history: 21-Jul-88, Version 1 by Pitman
06-Oct-88, Version 2 by Pitman
9-May-89, Version 3 by Moon (small fixes)
10-May-89, Version 4 by Moon (add two more functions)
13-May-89, Version 5 by Moon (minor cleanups, add clarification)
Problem Description:
Some file systems provide more complex conventions for wildcards than
simple component-wise wildcards (:WILD). For example,
"F*O" might mean:
- a normal three character name
- a three-character name, with the middle char wild
- at least a two-character name, with the middle 0 or more chars wild
- a wild match spanning multiple directories
">foo>*>bar" might imply:
- the middle directory is named "*"
- the middle directory is :WILD
- there may be zero or more :WILD middle directories
- the middle directory name matches any one-letter name
">foo>**>bar" might mean
- the middle directory is named "**"
- the middle directory is :WILD
- there may be zero or more :WILD middle directories
- the middle directory name matches any two-letter name
Some file systems support even more complex wildcards, for example
regular expressions.
The CL pathname model does not specify a way to represent complex
wildcards, which means, for example, that (MAKE-PATHNAME :NAME "F*O")
cannot be recognized by portable code as containing a wildcard.
Common Lisp provides only the first of these four common operations
on wildcard pathnames:
(1) Enumerate the set of existing files that match the pathname;
this is provided by the DIRECTORY function.
(2) Test whether a pathname contains wildcards.
(3) Test whether a pathname matches a wildcard pathname.
(4) Translate one pathname into another according to a mapping specified
by a pair of wildcard pathnames.
Proposal (PATHNAME-WILD:NEW-FUNCTIONS):
Introduce the following three functions:
WILD-PATHNAME-P pathname &optional field-key
Tests a pathname for the presence of wildcard components. If the first
argument is not a pathname, string, or file stream an error of type
TYPE-ERROR is signalled.
If no <field-key> is provided, or the <field-key> is NIL, the result is
T if <pathname> has any wildcard components, NIL if <pathname> has none.
If a non-null <field-key> is provided, it must be one of :HOST, :DEVICE,
:DIRECTORY, :NAME, :TYPE, or :VERSION. In this case, the result is T
if the indicated component of <pathname> is a wildcard, NIL if the
component is not a wildcard.
PATHNAME-MATCH-P pathname wildcard
T if <pathname> matches <wildcard>, otherwise NIL. The matching rules
are implementation-dependent but should be consistent with the
DIRECTORY function. Missing components of <wildcard> default to :WILD.
If either argument is not a pathname, string, or file stream an error
of type TYPE-ERROR is signalled. It is valid for <pathname> to be a
wild pathname. It is valid for <wildcard> to be a non-wild pathname.
TRANSLATE-PATHNAME source from-wildcard to-wildcard &optional reversible
Translate the pathname <source> according to the correspondence between
the two wildcard pathnames. This translation is implementation
dependent. The result is <to-wildcard> with each missing or wildcard
field replaced by the portion of <source> that matches the corresponding
field (usually a wildcard) in <from-wildcard>. Additional translations
of alphabetic case or file naming conventions might also occur,
especially when from-wildcard and to-wildcard are for different hosts.
If <reversible> is false, the translation is determined by the user
interface conventions of the file systems involved. If <reversible> is
true, the translation must instead be reversible, that is, the
following identity must hold for all cases where no error is signalled:
(equal (translate-pathname (translate-pathname pathname from to t)
to from t)
pathname)
In some file systems the above identity is true only when
(member (pathname-version pathname) '(:newest :unspecific)).
This is considered valid, as Common Lisp cannot force all the
file systems in the world to implement versions.
In some file systems the <reversible> argument is ignored because the
user interface conventions are reversible anyway.
If any of the first three arguments is not a pathname, string, or file
stream an error of type TYPE-ERROR is signalled. It is valid for
<source> to be a wild pathname; in general this will produce a wild
result. It is valid for <from-wildcard> and/or <to-wildcard> to be
non-wild pathnames. (PATHNAME-MATCH-P <source> <from-wildcard>) must
be true or an error is signalled.
Implementation guideline: one typical file system performs this
operation by examining each field of the pathnames in turn, where a
field is a component or an element of a structured component such as a
hierarchical directory. Hierarchical directory elements in
<from-wildcard> and <to-wildcard> are matched by whether they are
wildcards, not by depth in the directory hierarchy. If the field in
<from-wildcard> does not match the field in <source>, an error is
signalled. If the field in <to-wildcard> is present and not wild, it
is copied into the result. If the field in <to-wildcard> is :WILD or
NIL, and either <reversible> is false or the field in <from-wildcard>
is not a complex wildcard, the field in <source> is copied into the
result. Otherwise, the field in <to-wildcard> might be a complex
wildcard such as "foo*bar" and the field in <from-wildcard> should be
wild; the portion of the field in <source> that matches the wildcard
portion of the field in <from-wildcard> fills in the wildcard portion
of the field in <to-wildcard> and the field value produced is used in
the result.
Clarify that the functions OPEN (and WITH-OPEN-FILE), RENAME-FILE,
DELETE-FILE, PROBE-FILE, FILE-WRITE-DATE, FILE-AUTHOR, LOAD,
COMPILE-FILE, and TRUENAME only accept non-wildcard pathnames and signal
an error if given a pathname for which WILD-PATHNAME-P returns true.
Examples:
(WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD)) => T
(WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD) :NAME) => T
(WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD) :TYPE) => NIL
(WILD-PATHNAME-P (PATHNAME "S:>foo>**>")) => T ;Lispm
(WILD-PATHNAME-P (PATHNAME :NAME "F*O")) => T ;Most places
;This example assumes one particular set of wildcard conventions
;Not all file systems will run this example exactly as written
(DEFUN RENAME-FILES (FROM TO)
(DOLIST (FILE (DIRECTORY FROM))
(RENAME-FILE FILE (TRANSLATE-PATHNAME FILE FROM TO))))
(RENAME-FILES "/usr/me/*.lisp" "/dev/her/*.l")
;Renames /usr/me/init.lisp to /dev/her/init.l
(RENAME-FILES "/usr/me/pcl*/*" "/sys/pcl/*/")
;Renames /usr/me/pcl-5-may/low.lisp to /sys/pcl/pcl-5-may/low.lisp
;In some file systems the result might be /sys/pcl/5-may/low.lisp
(RENAME-FILES "/usr/me/pcl*/*" "/sys/library/*/")
;Renames /usr/me/pcl-5-may/low.lisp to /sys/library/pcl-5-may/low.lisp
;In some file systems the result might be /sys/library/5-may/low.lisp
(RENAME-FILES "/usr/me/foo.bar" "/usr/me2/")
;Renames /usr/me/foo.bar to /usr/me2/foo.bar
;This example assumes one particular set of wildcard conventions and
;illustrates how and why reversible translation uses different rules
(PATHNAME-NAME (TRANSLATE-PATHNAME "foobar" "foo*" "*baz" NIL)) => "barbaz"
(PATHNAME-NAME (TRANSLATE-PATHNAME "foobar" "foo*" "*baz" T)) => "barbaz"
(PATHNAME-NAME (TRANSLATE-PATHNAME "foobar" "foo*" "*" NIL)) => "foobar"
(PATHNAME-NAME (TRANSLATE-PATHNAME "foobar" "foo*" "*" T)) => "bar"
(PATHNAME-NAME (TRANSLATE-PATHNAME "foobar" "*" "foo*" NIL)) => "foofoobar"
(PATHNAME-NAME (TRANSLATE-PATHNAME "foobar" "*" "foo*" T)) => "foofoobar"
(PATHNAME-NAME (TRANSLATE-PATHNAME "bar" "*" "foo*" NIL)) => "foobar"
(PATHNAME-NAME (TRANSLATE-PATHNAME "bar" "*" "foo*" T)) => "foobar"
;This example presumes background information described in PATHNAME-LOGICAL
(DEFUN TRANSLATE-LOGICAL-PATHNAME-1 (PATHNAME RULES)
(LET ((RULE (ASSOC PATHNAME RULES :TEST #'PATHNAME-MATCH-P)))
(UNLESS RULE (ERROR "No translation rule for ~A" PATHNAME))
(TRANSLATE-PATHNAME PATHNAME (FIRST RULE) (SECOND RULE) T)))
(TRANSLATE-LOGICAL-PATHNAME-1 "FOO:CODE;BASIC.LISP"
'(("FOO:DOCUMENTATION;" "MY-UNIX:/doc/foo/")
("FOO:CODE;" "MY-UNIX:/lib/foo/")
("FOO:PATCHES;*;" "MY-UNIX:/lib/foo/patch/*/")))
=> the pathname MY-UNIX:/lib/foo/basic.l
Rationale:
These three functions provide a standardized interface to the
idiosyncratic wildcard functionality of each host file system.
WILD-PATHNAME-P makes it possible to detect wild pathnames reliably and
do something useful (give up, merge out the bothersome components, call
DIRECTORY for a list of matching pathnames, etc.)
TRANSLATE-PATHNAME is needed by many application programs that deal with
wildcard pathnames. PATHNAME-MATCH-P and TRANSLATE-PATHNAME are needed
by logical pathnames. The reversible feature is needed by logical
pathnames.
Current Practice:
Presumably no implementation supports the proposal exactly as stated.
Symbolics Genera has had similar features under different names for many
years:
(SEND pathname :WILD-P) returns a value such as NIL, :NAME, :TYPE,
etc., indicating the first wild field.
(SEND pathname :NAME-WILD-P), (SEND pathname :DIRECTORY-WILD-P),
etc. test individual fields.
The :TRANSLATE-WILD-PATHNAME, :TRANSLATE-WILD-PATHNAME-REVERSIBLE, and
:PATHNAME-MATCH messages resemble TRANSLATE-PATHNAME and
PATHNAME-MATCH-P.
The clarification is current practice as far as the authors are aware.
If some implementations are found that specify a meaning for wildcard
pathnames as arguments to these functions, this proposal should be changed
to say that the consequences are unspecified rather than signalling an error.
Cost to Implementors:
Many implementations probably have a substrate which is capable of this
or something similar already. In such cases, it's a relatively small
matter to add the proposed interface.
Even in cases where an implementation doesn't have ready code, it's clearly
better for the implementor to write that code once and for all than to ask
each user of wildcards to write it.
Since the detailed behavior is at the implementor's discretion, the cost
is unlikely to be large. Some file systems will do all the work and the
implementor need only provide an interface to the file system or to a
standard library routine. For other file systems the implementor has to
write the actual matching and translation algorithms.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Wild pathnames would continue to be mistaken for ordinary pathnames in
many situations. User programs that deal with wildcard pathnames would
have to operate on implementation-dependent representations and hence
would not be easily portable.
The biggest cost is that any logical pathnames proposal would be stymied.
Performance Impact:
None.
Benefits:
A more complete set of wildcard pathname operations. Portable user
programs that deal with wildcard pathnames will be more consistent
and reliable. A portable system construction tool can be written
and the foundations are laid for a `logical pathname' facility
(proposed separately in PATHNAME-LOGICAL).
Aesthetics:
This change would make some portable code less kludgey.
Discussion:
There was some question about the name. The name PATHNAME-WILD-P
suggests a ``slot'' of a pathname (like PATHNAME-HOST),
while WILD-PATHNAME-P suggests a type (like INPUT-STREAM-P).
The committee was split on what to call it. Since it is more
like a type than a slot, the name WILD-PATHNAME-P was chosen.
∂23-May-89 1148 CL-Cleanup-mailer Issue: DATA-IO (version 6)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 23 May 89 11:47:55 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 599434; 23 May 89 14:25:29 EDT
Date: Tue, 23 May 89 14:29 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DATA-IO (version 6)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19890523182956.9.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
This is a new issue. It arose from an investigation of features
that are plausibly needed but missing from draft ANSI Common Lisp.
This issue seems sufficiently simple and noncontroversial that
I would like to see it on the agenda for the June X3J13 meeting.
Let's use the cleanup subcommittee to test the assertion that this
is a simple and noncontroversial issue. If it's controversial,
let's just drop it, otherwise let's give X3J13 a chance to vote
for or against it.
Issue: DATA-IO
References: CLtL pp.360, 370, 382
Related issues: none
Category: ADDITION
Edit history: Version 1, 9-May-89, by Moon
Version 2, 10-May-89, by Moon
(clarify ambiguities, add PRINT-UNREADABLE-OBJECT)
Version 3, 18-May-89, by Moon (respond to KMP's comments)
Version 4, 21-May-89, by Moon (almost-final cleanup)
Version 5, 22-May-89, by Pitman (``never say never'')
Version 6, 23-May-89, by Moon (final cleanup)
Problem description:
Storing data in textual form in files, as Lisp expressions, is common
practice but has some pitfalls. Files can be unreadable if #<...> syntax
is written by the printer, or if the reader syntax or package varies
between writing and reading. Files of data intended to be carried from
one Lisp implementation to another can fail to read correctly if
implementation-dependent syntax extensions get used when not intended.
CLtL p.370 recommends that unreadable objects be printed with #<...>
syntax including implementation-dependent information. Now that users
can write their own PRINT-OBJECT methods, a way is needed for such
methods to print this syntax without any implementation-dependent coding.
Proposal (DATA-IO:ADD-SUPPORT):
Add a new variable *PRINT-READABLY*. Add a corresponding keyword
argument :READABLY to WRITE. The default value of *PRINT-READABLY* is
NIL. If :READABLY (which defaults to *PRINT-READABLY*) is true, then
printing any object produces a printed representation that the reader
will accept. If this is not possible, the printer signals an error of
type PRINT-NOT-READABLE rather than using an unreadable syntax such as
#<...>. The printed representation produced when :READABLY is true might
or might not be the same as the printed representation produced when
:READABLY is false.
All methods for PRINT-OBJECT must obey *PRINT-READABLY*. This includes
both user-defined methods and implementation-defined methods.
Printed representations produced when *PRINT-READABLY* is true and
*PRINT-ESCAPE* is false might or might not be readable.
Setting *PRINT-ESCAPE* to false might or might not prevent errors of type
PRINT-NOT-READABLE from being signalled.
Add two new macros:
WITH-STANDARD-IO-SYNTAX &body body [Macro]
Within the dynamic extent of <body>, all reader/printer control
variables, including any implementation-defined ones not specified by
Common Lisp, are bound to values that produce standard read/print
behavior. The values for Common Lisp specified variables are:
*PACKAGE* The USER package
*PRINT-ARRAY* T
*PRINT-BASE* 10
*PRINT-CASE* :UPCASE
*PRINT-CIRCLE* NIL
*PRINT-ESCAPE* T
*PRINT-GENSYM* T
*PRINT-LENGTH* NIL
*PRINT-LEVEL* NIL
*PRINT-PRETTY* NIL
*PRINT-RADIX* NIL
*PRINT-READABLY* T
*READ-BASE* 10
*READ-DEFAULT-FLOAT-FORMAT* SINGLE-FLOAT
*READ-SUPPRESS* NIL
*READTABLE* The standard readtable
PRINT-UNREADABLE-OBJECT (object stream &key type identity) [Macro]
&body body
Output a printed representation of <object> on <stream>, beginning with
"#<" and ending with ">". Everything output to <stream> by the <body>
forms is enclosed in the angle brackets. If :type is true, the body
output is preceded by a brief description of the object's type and a
space character. If :identity is true, the body output is followed by
a space character and a representation of the object's identity,
typically a storage address.
If *PRINT-READABLY* is true, PRINT-UNREADABLE-OBJECT signals an error
of type PRINT-NOT-READABLE without printing anything.
The <object>, <stream>, :type, and :identity arguments are all evaluated
normally. :type and :identity default to false. It is valid to omit
the <body> forms. If :type and :identity are both true and there are no
<body> forms, only one space character separates the type and the identity.
Add a new condition type:
PRINT-NOT-READABLE [Type]
Errors which occur during output while *PRINT-READABLY* is true, as a
result of attempting to output a printed representation that cannot be
read back, should inherit from this type. This is a subtype of ERROR.
The init keyword :OBJECT is supported to initialize the slot containing
the object being printed, which can be accessed using
PRINT-NOT-READABLE-OBJECT.
Examples:
;; Example #1: Reliable Write-Read
(WITH-OPEN-FILE (FILE pathname :DIRECTION :OUTPUT)
(WITH-STANDARD-IO-SYNTAX
(PRINT DATA FILE)))
; ... Later, in another Lisp:
(WITH-OPEN-FILE (FILE pathname :DIRECTION :INPUT)
(WITH-STANDARD-IO-SYNTAX
(SETQ DATA (READ FILE))))
;; Example #2: Use of PRINT-UNREADABLE-OBJECT
;; Note that in this example, the precise form of the output
;; is really implementation-dependent.
(DEFMETHOD PRINT-OBJECT ((OBJ AIRPLANE) STREAM)
(PRINT-UNREADABLE-OBJECT (OBJ STREAM :TYPE T :IDENTITY T)
(PRINC (TAIL-NUMBER OBJ) STREAM)))
(PRINT MY-AIRPLANE)
#<Airplane NW0773 36000123135> ;in Implementation A
;or
#<FAA:AIRPLANE NW0773 17> ;in Implementation B
Rationale:
*PRINT-READABLY* is important so that errors involving data with no
readable printed representation are detected when writing the file, not
later on when the file is read.
*PRINT-READABLY* is different from *PRINT-ESCAPE* because output printed
with escapes only has to be generally recognizable by humans, whereas
output printed readably has to be reliably recognizable by computers.
Providing the WITH-STANDARD-IO-SYNTAX macro to bind all the variables,
instead of using LET and explicit bindings of the existing variables,
ensures that nothing is overlooked and avoids problems with
implementation-defined reader/printer control variables.
If the user wishes to use a non-standard value for some variable, most
commonly *PACKAGE*, it can be bound by LET inside the body of
WITH-STANDARD-IO-SYNTAX. Similarly, if the user dislikes the somewhat
arbitrary choices of values for *PRINT-CIRCLE* and *PRINT-PRETTY*, they
can be bound to the preferred values inside the body.
Current practice:
Symbolics Genera has had these features for many years, except that
WITH-STANDARD-IO-SYNTAX is named WITH-STANDARD-IO-ENVIRONMENT and binds
*PACKAGE* to a non-standard package. The new name both is more accurate
and avoids compatibility problems for Genera.
Genera's WITH-STANDARD-IO-ENVIRONMENT also disables #., to prevent trojan
horses, since #. could evaluate an arbitrary form. This is particularly
important for network protocols. This feature is not being proposed for
Common Lisp at this time as it would prevent using #. in the printer for
common datatypes, which is current practice in some implementations. #.
suppression could be a separate reader/printer control variable.
In Genera, PRINT-UNREADABLE-OBJECT is called SYS:PRINTING-RANDOM-OBJECT
and takes slightly different arguments. In PCL, PRINT-UNREADABLE-OBJECT
is called PCL:PRINTING-RANDOM-THING.
Cost to Implementors:
Very small.
Cost to Users:
None if they don't use the feature. Otherwise just the cost of
supporting *PRINT-READABLY* or using PRINT-UNREADABLE-OBJECT in their
PRINT-OBJECT methods.
Cost of non-adoption:
There will be no reliable, standard way to write data into a file.
Performance impact:
Negligible. Entering WRITE may be slightly slower since there is
one more keyword argument to parse and one more special variable
to bind before calling PRINT-OBJECT.
Benefits:
Data can be written into files reliably without resorting to
implementation-specific programming.
Esthetics:
Mildly improved.
Discussion:
Pitman and Moon support this proposal.
∂23-May-89 1148 CL-Cleanup-mailer Issue: STRING-COERCION (version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 23 May 89 11:48:21 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 599438; 23 May 89 14:29:55 EDT
Date: Tue, 23 May 89 14:34 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STRING-COERCION (version 2)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19890523183420.0.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
This is a new issue. This issue seems sufficiently simple and
noncontroversial that I would like to see it on the agenda for the June
X3J13 meeting. Let's use the cleanup subcommittee to test the assertion
that this is a simple and noncontroversial issue. If it's
controversial, let's just drop it, otherwise let's give X3J13 a chance
to vote for or against it.
Issue: STRING-COERCION
References: Strings (pp299-304),
STRING= (p300), STRING-EQUAL (p301), STRING< (p301),
STRING> (p301), STRING<= (p301), STRING>= (p301),
STRING/= (p301), STRING-LESSP (p302), STRING-GREATERP (p302),
STRING-NOT-GREATERP (p302), STRING-NOT-LESSP (p302),
STRING-NOT-EQUAL (p302), STRING-TRIM (p302), STRING-LEFT-TRIM (p302),
STRING-RIGHT-TRIM (p302), STRING-UPCASE (p303), STRING-DOWNCASE (p303),
and STRING-CAPITALIZE (p303).
Related issues: none
Category: CLARIFICATION
Edit history: Version 1, 9-May-89 by Moon
Version 2, 9-May-89 by Pitman (editorial changes)
Problem description:
CLtL is inconsistent about the argument coercion performed by the
referenced functions. Page 299 says that the <string> argument can
be either a symbol or a string. Page 304 says that these functions
effectively call the STRING function, thus accepting a symbol,
a string, or a character.
Neither page lists the set of affected functions explicitly.
Page 304 says that if any other data type is used, an error is
signalled. But some implementations allow other types, such as
pathnames, to be coerced to strings, which page 299 appears to allow
but page 304 appears to forbid. In some implementations these
coercions are under user control via methods for a generic function.
Proposal (STRING-COERCION:MAKE-CONSISTENT):
Specify that the referenced functions perform coercion identical to
the action of the STRING function.
Specify that the STRING function can perform additional implementation
dependent coercions. In all cases the returned value is of type STRING.
Only in the case where no coercion is defined is the STRING function
required to signal an error; in that case, the error is of type TYPE-ERROR.
Examples:
(string-lessp #\a "B") => T
Rationale:
Our choices are to make the coercion identical to the STRING function,
identical to the COERCE function, or different from both of them. The
COERCE function won't coerce non-null symbols to strings, so it is out.
Being consistent with the STRING function seems better than inventing
yet another set of string coercion rules. Removing the ability for the
STRING function to coerce characters to strings would be an incompatible
change, so instead we clarify that the other functions have that ability.
Allowing additional coercions is harmless and consistent with current
practice.
Current practice:
Symbolics Genera follows page 304 except for allowing additional
coercions. Symbolics Cloe follows page 299 except for not allowing
additional coercions.
Cost to Implementors:
Small changes to eighteen functions.
Cost to Users:
None, this is upward-compatible.
Cost of non-adoption:
Inconsistency and confusion about what coercions are allowed.
Performance impact:
None. If these things have to accept symbols, accepting characters
too can't make much difference. The implementation of character
arguments to string functions might cons a string, but this has no
performance impact on programs that don't use the feature.
Benefits:
Consistency.
Esthetics:
Consistency.
Discussion:
None.
∂23-May-89 1148 CL-Cleanup-mailer Issue: BIT-ARRAY-FUNCTIONS (version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 23 May 89 11:48:21 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 599444; 23 May 89 14:38:13 EDT
Date: Tue, 23 May 89 14:42 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: BIT-ARRAY-FUNCTIONS (version 5)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19890523184240.1.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
This is a new issue. It arose from an investigation of features
that are plausibly needed but missing from draft ANSI Common Lisp.
This issue seems sufficiently simple and noncontroversial that
I would like to see it on the agenda for the June X3J13 meeting.
Let's use the cleanup subcommittee to test the assertion that this
is a simple and noncontroversial issue. If it's controversial,
let's just drop it, otherwise let's give X3J13 a chance to vote
for or against it.
Issue: BIT-ARRAY-FUNCTIONS
References: The binary bit-array functions BIT-AND, BIT-IOR, BIT-XOR,
BIT-EQV, BIT-NAND, BIT-NOR, BIT-ANDC1, BIT-ANDC2, BIT-ORC1,
and BIT-ORC2 (CLtL p.294).
The unary bit-array function BIT-NOT (CLtL p.295).
The mapping functions EVERY, MAP, NOTANY, NOTEVERY, and SOME
(CLtL pp.249-250).
The functions COUNT and POSITION (CLtL p.257).
Related issues: none
Category: ADDITION
Edit history: Version 1, 9-May-89, by Moon
Version 2, 10-May-89, by Moon (add second proposal)
Version 3, 12-May-89, by Moon (small wording improvements)
Version 4, 13-May-89, by Moon (make more understandable)
Version 5, 23-May-89, by Moon (fix -p naming convention)
Problem description:
Logical operations on bit vectors have been found to be useful in such
programs as compiler flow analysis. They are easy to implement in
straight Common Lisp, but such an implementation is many times slower
than an optimized implementation on most machines. This is partly
because many machines have instructions to perform these operations or
inner kernels of them, and partly because Common Lisp is not a good
language for implementing this type of low-level bit-oriented operation.
Common Lisp provides some logical operations on bit arrays, but the
provided set is incomplete. Furthermore, the operations that are
provided are only defined for arrays of identical dimensions, making them
less useful for bit vectors that represent sets, where trailing zero
elements are often omitted. Some of the sequence functions are useful
for bit vectors, but users (correctly) fear that their implementation may
be optimized for general sequences, not for bit vectors.
This issue contains two alternative proposals.
Proposal (BIT-ARRAY-FUNCTIONS:ADD):
Allow the binary bit-array functions referenced above to accept arguments
of identical rank but unequal dimensions. Nonexistent elements of
bit-array-1 or bit-array-2 are assumed to be zero. If the third argument
is T or a bit-array, result elements outside the bounds of the array must
be zero or an error should be signalled. If the third argument is NIL or
omitted, each dimension of the result array is equal to either the
corresponding dimension of bit-array-1 or the corresponding dimension of
bit-array-2. The larger of the two dimensions is used when necessary to
hold all the nonzero elements of the result, otherwise either the larger
or the smaller of the two dimensions is used.
Allow BIT-NOT with a bit array as the second argument to accept arguments
of identical rank but unequal dimensions. Result elements outside the
bounds of the array must be zero or an error should be signalled.
Add the following functions:
BIT-SUBSETP bit-array-1 bit-array-2
Returns true if for every element of bit-array-1 that is 1, the
element with the same subscripts exists in bit-array-2 and is 1.
Bit-array-1 and bit-array-2 must have identical rank but need not
have identical dimensions.
BIT-DISJOINTP bit-array-1 bit-array-2
Returns true if for every element of one bit-array that is 1, the
element with the same subscripts either does not exist in the other
bit-array or is 0. Bit-array-1 and bit-array-2 must have identical
rank but need not have identical dimensions.
BIT-EQUALP bit-array-1 bit-array-2
Returns true if for every element of one bit-array that is 1, the
element with the same subscripts exists in the other bit-array and
is 1. Bit-array-1 and bit-array-2 must have identical rank but need
not have identical dimensions.
Suggest in the language specification document that compilers should
optimize the following functions when the sequence argument is declared
to be a bit-vector, taking advantage of any relevant special machine
instructions.
COUNT
POSITION
Suggest in the language specification document that compilers should
optimize the following functions when there are two arguments, the second
argument is declared to be a bit-vector, and the predicate argument is
#'ZEROP, taking advantage of any relevant special machine instructions.
EVERY
NOTANY
NOTEVERY
SOME
Proposal (BIT-ARRAY-FUNCTIONS:NO-NEW-FUNCTIONS):
Same as BIT-ARRAY-FUNCTIONS:ADD but do not add the three new functions.
Instead, generalize the mapping functions referenced above (EVERY, MAP,
NOTANY, NOTEVERY, and SOME) so that they operate on "mappables" rather
than just sequences. Define a mappable to be an array or a list.
Specify that the mappable arguments to a mapping function, and the result
in the case of MAP with a non-NIL first argument, must all be of the same
rank (the rank of a list is considered to be 1). Mapping accesses array
elements in row-major order. Generalize the existing specification that
a mapping function uses the length of the shortest sequence, to say that
a mapping function uses on each axis the minimum of the dimensions on
that axis of the mappable arguments.
Suggest in the language specification document that compilers should
optimize the functions EVERY, NOTANY, NOTEVERY, and SOME when there are
two arguments, the second argument is declared to be a bit-array, and the
predicate argument is #'ZEROP, taking advantage of any relevant special
machine instructions. In addition compilers should optimize when the
second argument is a call with two arguments to one of the binary
bit-array functions referenced above, to avoid consing an intermediate
result.
Examples:
The equivalents of UNION and INTERSECTION for sets represented
as bit vectors, with 1's in positions where set elements are
present, are BIT-IOR and BIT-AND respectively.
(COUNT 1 (THE BIT-VECTOR BV)) computes the cardinality of a bit
vector (called the population on some computers). This is
analogous to LOGCOUNT of an integer.
(POSITION BIT (THE BIT-VECTOR BV)) scans for a 1 or 0 bit, but
can likely be implemented using a word-at-a-time scan.
(EVERY #'ZEROP (THE BIT-VECTOR BV)) tests whether a bit vector
is entirely zero.
(BIT-SUBSETP bit-array-1 bit-array-2) is equivalent to
(EVERY #'ZEROP (BIT-ANDC2 bit-array-1 bit-array-2)) [under
the first proposal, only when the arguments are of rank 1.]
(BIT-DISJOINTP bit-array-1 bit-array-2) is equivalent to
(EVERY #'ZEROP (BIT-AND bit-array-1 bit-array-2)) [under
the first proposal, only when the arguments are of rank 1.]
This is analogous to NOT of LOGTEST of two integers.
(BIT-EQUALP bit-array-1 bit-array-2) is equivalent to
(EVERY #'ZEROP (BIT-XOR bit-array-1 bit-array-2)) [under
the first proposal, only when the arguments are of rank 1.]
BIT-EQUALP differs from EQUAL only when the arguments are of
unequal dimensions.
Rationale:
Three new functions are added by BIT-ARRAY-FUNCTIONS:ADD because EVERY
only works on vectors, since issue SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS was
rejected. BIT-ARRAY-FUNCTIONS:NO-NEW-FUNCTIONS includes the minimal
portion of that proposal needed to avoid adding any new functions, while
omitting all the controversial parts.
The suggestion for compiler optimization is to give users the confidence
that they will get good results when using sequence and mapping
operations on bit vectors. Otherwise we would feel the need to add
additional bit-vector-specific functions to perform these operations in a
way that is optimized and specialized for bit-vectors.
Recommending optimization of a particular way of performing these
operations avoids the problem of each implementation choosing a different
idiom to optimize, resulting in performance problems when porting.
Relaxing the requirement that bit arrays must have equal dimensions was
requested by users who had tried to use these operations on sets. The
loose specification of the result dimensions is to allow maximum
implementation freedom. This is not essential to the proposal and could
be changed to require that the result have the same dimension as the
larger of the two arguments.
Current practice:
Symbolics Genera 7.2 has something like the first proposal, but only for
bit vectors, not generalized for bit arrays. Genera has some additional
functions (BIT-VECTOR-POSITION, BIT-VECTOR-CARDINALITY, and
BIT-VECTOR-ZERO-P) that aren't really necessary since they are equivalent
to POSITION, COUNT, or EVERY plus a type declaration. The proposal seems
to fit into the rest of Common Lisp better than Genera's current practice.
Cost to Implementors:
Implementing these very efficiently may require some clever hand coding.
Of course the standard cannot mandate any particular level of efficiency
and a simple, low-cost implementation is permissible. Implementing the
compiler suggestions requires keeping track of type declarations in the
compiler, but most compilers already do that. The second proposal
requires slightly more compiler analysis than the first proposal.
A run-time type test and dispatch to code specialized for bit-arrays
could be used instead of compiler analysis, at a small efficiency cost.
Cost to Users:
None.
Cost of non-adoption:
Less featureful language. Some bit array manipulation will have to be
written in nonportable Lisp code or in C or assembly language.
Performance impact:
None on programs that don't use these features. Negligibly small on
the binary bit-array functions referenced above when array dimensions
are equal. Large improvement for programs that can take advantage of
these features when running in an implementation that optimizes them.
Benefits:
More featureful language.
Esthetics:
More featureful language.
Discussion:
This functionality was suggested on the Common Lisp mailing list
12-Jan-89. The detailed design has evolved from what was suggested and
is greatly simplified.
∂23-May-89 1148 CL-Cleanup-mailer Issue: PATHNAME-SYSTEM-TYPE (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 23 May 89 11:47:58 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 599426; 23 May 89 14:02:37 EDT
Date: Tue, 23 May 89 14:06 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SYSTEM-TYPE (version 1)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19890523180657.8.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
This is a new issue. It arose from an investigation of features
that are plausibly needed but missing from draft ANSI Common Lisp.
This issue seems sufficiently simple and noncontroversial that
I would like to see it on the agenda for the June X3J13 meeting.
Let's use the cleanup subcommittee to test the assertion that this
is a simple and noncontroversial issue. If it's controversial,
let's just drop it, otherwise let's give X3J13 a chance to vote
for or against it.
Issue: PATHNAME-SYSTEM-TYPE
References: Internet RFC 1010, pages 24-25
Related issues: PATHNAME-LOGICAL
Category: ADDITION
Edit history: 23-May-89, Version 1 by Moon
Problem description:
It is sometimes necessary to write nonportable pathname manipulation code
that performs operations specific to individual file systems. Sometimes
this is to get around inadequacies of the Common Lisp pathname model,
sometimes it is to take advantage of idiosyncratic features of a
particular file system. Common Lisp does not provide any way to ask what
file system a pathname is for, so there is no good way for this type of
pathname manipulation code to be sure what file system it is dealing
with. Sometimes it can tell by checking what Lisp implementation it is
running in, but as more and more implementations support network file
access, this is becoming less reliable.
Proposal (PATHNAME-SYSTEM-TYPE:ADD-FUNCTION):
Add the following function:
PATHNAME-SYSTEM-TYPE pathname [Function]
Coerce the pathname argument to a pathname, signalling an error of type
TYPE-ERROR if the argument is not a pathname, string, or file stream.
Return a keyword symbol that identifies the type of file system this
pathname is for. The names of these symbols are derived from the
system type names used by the Internet Domain Name system, listed in
the referenced document. Implementations that use a file system listed
in that document, or superseding documents, should return a symbol in
the keyword package whose name comes from that document. Examples:
:MSDOS MS/DOS or PC/DOS
:TOPS10 TOPS-10
:TOPS20 TOPS-20
:ULTRIX Ultrix
:UNIX Unix with long file names (4.2 or newer)
:VM/370 VM/370
:VMS VAX/VMS with long file names (version 4.4 or newer)
:XENIX Xenix
The following additional symbols are specified by Common Lisp:
:LOGICAL logical pathname (see issue PATHNAME-LOGICAL)
:UNIX-14 Unix with 14-character file name limit
:VMS-9 VAX/VMS with 9-character file name limit
NIL system type cannot be determined
For file systems not named in the referenced document, implementations
should make up a name consistent with the spelling conventions defined
in that document.
Examples:
;; On a non-networked IBM PC:
(PATHNAME-SYSTEM-TYPE (USER-HOMEDIR-PATHNAME)) => :MSDOS
Rationale:
PATHNAME-SYSTEM-TYPE gives a nonportable pathname manipulation program
the basic information it needs to interpret namestrings and manipulate
pathname components.
Current practice:
Symbolics Genera has had a similar feature under a different name
for many years. A few of the keyword symbols returned by Genera
are spelled differently, merely for historical reasons.
Cost to Implementors:
Trivial.
Cost to Users:
None.
Cost of non-adoption:
Implementation-dependent kludges will have to be used.
Performance impact:
None.
Benefits:
Improved esthetics.
Esthetics:
Implementation-dependent kludges will not have to be used.
Discussion:
None.
∂23-May-89 1228 CL-Cleanup-mailer Issue: STREAM-CAPABILITIES (version 3)
Received: from ALLEGHENY.SCRC.Symbolics.COM ([128.81.41.45]) by SAIL.Stanford.EDU with TCP; 23 May 89 12:28:02 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via INTERNET with SMTP id 140393; 23 May 89 14:42:53 EDT
Date: Tue, 23 May 89 14:46 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STREAM-CAPABILITIES (version 3)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19890523184654.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
I hope this issue is on the agenda for the June X3J13 meeting. KMP and
I have prepared a revised writeup which we think is ready for release.
I'd like to distribute this to X3J13 as soon as discussion, if any, in
the cleanup subcommittee is completed.
Issue: STREAM-CAPABILITIES
References: Standard streams (pp. 327-329)
Category: ADDITION
Edit history: Version 1 by Pierson 5-Jul-88, add redesign per Pitman
Version 2 by Moon, 10-May-89, remove controversial parts
Version 3 by Moon, 12-May-89, improve wording and examples
Problem description:
Programs cannot currently distinguish between interactive use and batch
(or background) use without using implementation-dependent extensions.
For example, there is currently no way to tell whether it is useful to
ask a question when an unexpected situation is encountered.
Note: earlier versions of this issue tried to solve another problem
as well. See discussion section.
Proposal (STREAM-CAPABILITIES:INTERACTIVE-STREAM-P):
Add the following function:
INTERACTIVE-STREAM-P stream
Returns T if the stream is interactive, otherwise NIL. Signals
an error of type TYPE-ERROR if the argument is not a stream.
The precise meaning of INTERACTIVE-STREAM-P is implementation
dependent, and may depend on the underlying operating system. However
the general intent is to distinguish between interactive and batch (or
background or command-file) operations.
Some examples of the things that might identify a stream as interactive
include:
1. The stream is connected to a person (or equivalent) in
such a way that the program can prompt for information and
expect to receive different input depending on the prompt.
2. The program is expected to prompt for input and support
"normal input editing".
3. READ-CHAR might hang waiting for the user to type something
instead of quickly returning a character or EOF.
*TERMINAL-IO* might or might not be interactive.
Examples:
(when (> measured limit)
(let ((error (round (* (- measured limit) 100)
limit)))
(unless (if (interactive-stream-p *query-io*)
(yes-or-no-p "The frammis is out of tolerance by ~D%.~@
Is it safe to proceed? " error)
(< error 15)) ;15% is acceptable
(error "The frammis is out of tolerance by ~D%." error))))
Rationale:
INTERACTIVE-STREAM-P has been proposed several times and is clearly
needed by any program that alters its behavior depending on whether
it is interacting with a user or running in a "batch" mode.
Current practice:
Most implementations have this feature already, often under a
different name.
Cost to Implementors:
Implementations will have to support this new function. Correct support
will require some thought for each operating system supported.
Cost to Users:
None, this is an upward-compatible extension.
Cost of non-adoption:
Less featureful language.
Performance impact:
None.
Benefits:
More featureful language.
Esthetics:
More featureful language.
Discussion:
Note that some proposed features for telling whether two streams are
connected to the same source or sink of information have been removed
from this version of the proposal. These were the functions
STREAM-SAME-SOURCE-P, STREAM-SAME-DESTINATION-P, STREAM-SOURCE-ID-LIST,
and STREAM-DESTINATION-ID-LIST. These could be revived in another
proposal if desired, but Moon thought INTERACTIVE-STREAM-P was
important and didn't want it to be lost due to controversy over these
unrelated functions.
∂23-May-89 1231 CL-Cleanup-mailer Issue: MAP-INTO (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 23 May 89 12:31:28 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 599485; 23 May 89 15:29:44 EDT
Date: Tue, 23 May 89 15:34 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: MAP-INTO (version 1)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19890523193408.6.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
This is a new issue. It arose from an investigation of features
that are plausibly needed but missing from draft ANSI Common Lisp.
This issue seems sufficiently simple and noncontroversial that
I would like to see it on the agenda for the June X3J13 meeting.
Let's use the cleanup subcommittee to test the assertion that this
is a simple and noncontroversial issue. If it's controversial,
let's just drop it, otherwise let's give X3J13 a chance to vote
for or against it.
Issue: MAP-INTO
References: none
Related issues: BIT-ARRAY-FUNCTIONS
Category: ADDITION
Edit history: 23-May-89, version 1 by Moon
Problem description:
The function MAP is very useful but can be a source of inefficiency
because it conses the result. Sometimes the user has storage
already allocated in which the result could be stored.
Proposal (MAP-INTO:ADD-FUNCTION):
Add the following function:
MAP-INTO result-sequence function &rest sequences [Function]
Destructively modifies the result-sequence to contain the results of
applying function to each element in the argument sequences in turn.
Returns result-sequence.
MAP-INTO differs from MAP in that it modifies an existing sequence
rather than creating a new one.
The arguments result-sequence and each element of sequences can each be
either a list or a vector (one-dimensional array). Note that nil is
considered to be a sequence, of length zero. If result-sequence and
each element of sequences are not all the same length, the iteration
terminates when the shortest sequence is exhausted.
If BIT-ARRAY-FUNCTIONS:NO-NEW-FUNCTIONS passes, then MAP-INTO will
allow result-sequence and each element of sequences to be mappables
all of the same rank.
The function must take at least as many arguments as there are
sequences provided, and at least one sequence must be provided.
If function has side effects, it can count on being called first on all
of the elements with index 0, then on all of those numbered 1, and so
on.
Examples:
(map-into x #'+ x y)
(map-into q #'cons keys vals)
Rationale:
MAP-INTO is a simple way to express reuse of storage that is
stylistically consistent with the rest of Common Lisp.
Current practice:
Symbolics Genera 7.2 implements the proposal.
Cost to Implementors:
Small.
Cost to Users:
None.
Cost of non-adoption:
Small.
Performance impact:
None.
Benefits:
More expressive language.
Esthetics:
User programs won't have to write the above examples as
(loop for xx on x and yy in y do
(setf (car xx) (+ (car xx) yy)))
or something else about equally horrible.
Discussion:
None.
∂23-May-89 1231 CL-Cleanup-mailer Issue: FLOAT-UNDERFLOW (version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 23 May 89 12:31:28 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 599463; 23 May 89 15:03:18 EDT
Date: Tue, 23 May 89 15:07 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FLOAT-UNDERFLOW (version 2)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19890523190746.4.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
This is a new issue. It arose from an investigation of features
that are plausibly needed but missing from draft ANSI Common Lisp.
This issue seems sufficiently simple and noncontroversial that
I would like to see it on the agenda for the June X3J13 meeting.
Let's use the cleanup subcommittee to test the assertion that this
is a simple and noncontroversial issue. If it's controversial,
let's just drop it, otherwise let's give X3J13 a chance to vote
for or against it.
Issue: FLOAT-UNDERFLOW
References: CLtL p.231
Related issues:LEAST-POSITIVE-SINGLE-FLOAT-NORMALIZATION (not written up),
ERROR-CHECKING-IN-NUMBERS-CHAPTER
Category: ADDITION and CLARIFICATION
Edit history: Version 1, 9-May-89, by Moon (suggested in January, but
the writeup was late)
Version 2, 23-May-89, by Moon (final cleanup for post-CLtL
changes to Common Lisp)
Problem description:
In implementations with denormalized floating point numbers (as in IEEE
floating point), which are closer to zero than any non-zero normalized
floating point numbers, should the LEAST-POSITIVE- and
MOST-POSITIVE-XXX-FLOAT constants be the normalized or denormalized
values? Which is preferred depends on the application. Note that in
IEEE floating point, denormalized results are normally only produced
as a result of underflow.
Also, there is no portable way to control what happens when a floating
point number underflows. Sometimes this is an error, sometimes not.
Indeed there is no mention at all of underflow or overflow in CLtL.
Pending issue ERROR-CHECKING-IN-NUMBERS-CHAPTER does not mention floating
point overflow or underflow. Draft ANSI Common Lisp specifies error
conditions named FLOATING-POINT-OVERFLOW and FLOATING-POINT-UNDERFLOW
but does not specify the circumstances in which they are signalled and
does not provide any way to suppress underflow checking.
Proposal (FLOAT-UNDERFLOW:ADD-CONTROLS):
Clarify that the existing LEAST-POSITIVE-XXX-FLOAT and
LEAST-NEGATIVE-XXX-FLOAT constants are literally as defined, and
therefore can be denormalized numbers in implementations that have
denormalized numbers.
Add the following constants, whose values are the normalized floating
point numbers closest in value to (but not equal to) zero. In
implementations that don't have denormalized numbers, the values of
these constants are the same as the values of the other constants.
LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT [Constant]
LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT [Constant]
LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT [Constant]
LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT [Constant]
LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT [Constant]
LEAST-POSITIVE-NORMALIZED-LONG-FLOAT [Constant]
LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT [Constant]
LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT [Constant]
Add the WITHOUT-FLOATING-UNDERFLOW-TRAPS macro. Within the dynamic
extent of its body, the result of a computation which would otherwise
underflow is a denormalized number or zero, whichever is closest to the
mathematical result.
Clarify that outside the dynamic extent of
WITHOUT-FLOATING-UNDERFLOW-TRAPS, a computation that underflows should
signal an error of type FLOATING-POINT-UNDERFLOW.
Clarify that a computation that underflows should signal an error of
type FLOATING-POINT-OVERFLOW.
Example: (not portable of course)
(expt 0.1 40) => error
(describe (without-floating-underflow-traps (expt 0.1 40))) =>
1.0e-40 is a single-precision floating-point number.
Sign 0, exponent 0, 23-bit fraction 213302 (denormalized)
Rationale:
The ANSI Common Lisp standard should be compatible with the
widely used IEEE Floating Point standard.
WITHOUT-FLOATING-UNDERFLOW-TRAPS is provided as a macro to allow
implementation flexibility. It could expand into HANDLER-BIND for
FLOATING-POINT-UNDERFLOW, but in most implementations it will probably
expand into implementation-dependent code that sets a hardware mode bit.
Specifying "should signal" rather than "signals" or "might signal" for
floating-point overflows and underflows seems the best balance between
safety and implementation freedom. It wouldn't harm the proposal to
change it to one of the other two phrases.
Current practice:
The proposal exactly matches Symbolics Genera release 7.
Cost to Implementors:
Adding the constants and the macro is easy. Since it was never clarified
that floating point underflow is to be detected in safe code, implementors
who had not already implemented that might have to go to some expense.
In the laissez-faire spirit of floating point in Common Lisp, we could
relax the specification and say only that underflow might signal rather
than should signal.
Cost to Users:
None.
Cost of non-adoption:
Each Common Lisp implementation that uses IEEE Floating Point will have
to invent its own way to deal with underflow and denormalized numbers.
Performance impact:
No effect on code optimized for speed.
Benefits:
Increased portability and correctness of floating point code.
Esthetics:
Neutral.
Discussion:
None.
∂24-May-89 0810 CL-Cleanup-mailer Issue: STREAM-CAPABILITIES (version 3)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 24 May 89 08:10:42 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA06685g; Wed, 24 May 89 08:09:35 PDT
Received: by bhopal id AA13071g; Wed, 24 May 89 08:09:16 PDT
Date: Wed, 24 May 89 08:09:16 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8905241509.AA13071@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 23 May 89 14:46 EDT <19890523184654.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Subject: Issue: STREAM-CAPABILITIES (version 3)
Looks simple enough. The evidence would be compelling if the guys
who argued so long about fixing the sequence functions to have
"re-usable" versions would lend their support as to the utility
of this thing.
-- JonL --
∂24-May-89 0816 CL-Cleanup-mailer Issue: FLOAT-UNDERFLOW (version 2)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 24 May 89 08:16:48 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA06744g; Wed, 24 May 89 08:15:43 PDT
Received: by bhopal id AA13086g; Wed, 24 May 89 08:15:24 PDT
Date: Wed, 24 May 89 08:15:24 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8905241515.AA13086@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 23 May 89 15:07 EDT <19890523190746.4.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Subject: Issue: FLOAT-UNDERFLOW (version 2)
Lucid 3.0 and later has LEAST-{NEGATIVE,POSITIVE}-NORMALIZED-<mumble>-FLOAT,
and in fact copied the names from Symbolics. These, and the prescription
that LEAST-{NEGATIVE,POSITIVE}-<mumble>-FLOAT be denormalized in
implementatons which support it, seem very non-controversial to me.
But WITHOUT-FLOATING-UNDERFLOW-TRAPS is too limited. The topic needs
more thought, because much more than "underflow" should be considered.
Lucid 3.0 and later has WITH-FLOATING-POINT-TRAPS, which takes two
lists of condition names relevant to floating point operations and
selectively enables or disables them (one list for "enablements", and
one for "disablements"). And I wouldn't like to bet on our being
able to achieve consensus on this design over the next few weeks,
even though I agree that it is an important topic.
-- JonL --
∂24-May-89 1013 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-CASE (version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 24 May 89 10:13:21 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 600008; 24 May 89 13:14:55 EDT
Date: Wed, 24 May 89 13:18 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-COMPONENT-CASE (version 4)
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <19890523171914.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Message-ID: <19890524171855.0.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
This line
Related-issues: PATHNAME-WILD-TRANSLATE
was a typo. The correct issue name is PATHNAME-WILD.
Sorry about that.
∂24-May-89 1024 CL-Cleanup-mailer Re: Issue: DATA-IO (version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 24 May 89 10:24:24 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 24 MAY 89 08:56:29 PDT
Date: Wed, 24 May 89 08:56 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Issue: DATA-IO (version 6)
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-6.text.newest
In-Reply-To: <19890523182956.9.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Message-ID: <19890524155620.2.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no
I support DATA-IO:ADD-SUPPORT.
-------
∂24-May-89 1112 CL-Cleanup-mailer Re: Issue: PATHNAME-LOGICAL (version 2)
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 May 89 11:12:38 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA25230@EDDIE.MIT.EDU>; Wed, 24 May 89 14:12:33 EDT
Received: by spt.entity.com (smail2.5); 24 May 89 12:52:13 EDT (Wed)
Date: Wed, 24 May 1989 12:52:12 EDT
From: Gail Zacharias <gz@spt.entity.com>
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@sail.stanford.edu
Subject: Re: Issue: PATHNAME-LOGICAL (version 2)
In-Reply-To: Your message of Tue, 23 May 89 13:21 EDT
Message-Id: <CMM.0.88.612031932.gz@spt.entity.com>
I really like this, except that I have a problem with the syntax - it looks
too much like the Macintosh pathname syntax. A name like "pcl:foo.lisp" can
be parsed as either a physical Macintosh pathname or a logical pathname. I
realize that the proposal is unambiguous on this point, resolving it in favor
of a logical pathname. But this means that a program defining a logical "pcl"
host thereby makes impossible for the user to access files on his physical
"pcl" disk. Note that TOPS-20, VMS and (I think) MSDOS have a similar
problem.
How about using "!" as the host separator?
∂24-May-89 1115 CL-Cleanup-mailer Issue: FLOAT-UNDERFLOW (version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 24 May 89 11:13:58 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 600010; 24 May 89 13:19:09 EDT
Date: Wed, 24 May 89 13:23 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FLOAT-UNDERFLOW (version 2)
To: Jon L White <jonl@lucid.com>
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <8905241515.AA13086@bhopal>
Message-ID: <19890524172312.2.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Date: Wed, 24 May 89 08:15:24 PDT
From: Jon L White <jonl@lucid.com>
Lucid 3.0 and later has LEAST-{NEGATIVE,POSITIVE}-NORMALIZED-<mumble>-FLOAT,
and in fact copied the names from Symbolics. These, and the prescription
that LEAST-{NEGATIVE,POSITIVE}-<mumble>-FLOAT be denormalized in
implementatons which support it, seem very non-controversial to me.
Thanks, I'll add that to the current practice section in the next version.
But WITHOUT-FLOATING-UNDERFLOW-TRAPS is too limited. The topic needs
more thought, because much more than "underflow" should be considered.
Lucid 3.0 and later has WITH-FLOATING-POINT-TRAPS, which takes two
lists of condition names relevant to floating point operations and
selectively enables or disables them (one list for "enablements", and
one for "disablements"). And I wouldn't like to bet on our being
able to achieve consensus on this design over the next few weeks,
even though I agree that it is an important topic.
The inability to converge on a design for such an elaborate feature is
precisely the reason for proposing the very simple feature. Also note
that underflow is the _only_ exception that some applications have a
very strong need to enable while at the same time other applications
have a very strong need to disable. Thus just the simple feature gets
us most of the way towards perfection. By the way if you want to write
up a proposal for the Lucid WITH-FLOATING-POINT-TRAPS so we can discuss
it, that would be fine with me. But I will be very disappointed if the
end result is that we can't agree on it and do nothing at all.
∂24-May-89 1117 CL-Cleanup-mailer Issue: STREAM-CAPABILITIES (version 3), or Issue: MAP-INTO (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 24 May 89 11:17:34 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 600032; 24 May 89 13:49:16 EDT
Date: Wed, 24 May 89 13:49 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STREAM-CAPABILITIES (version 3), or Issue: MAP-INTO (version 1)
To: jonl@lucid.com
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@sail.stanford.edu
In-Reply-To: <8905241509.AA13071@bhopal>
Message-ID: <19890524174912.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Wed, 24 May 89 08:09:16 PDT
From: Jon L White <jonl@lucid.com>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 23 May 89 14:46 EDT
<19890523184654.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Subject: Issue: STREAM-CAPABILITIES (version 3)
Looks simple enough. The evidence would be compelling if the guys
who argued so long about fixing the sequence functions to have
"re-usable" versions would lend their support as to the utility
of this thing.
-- JonL --
This is really a reply to Moon's MAP-INTO proposal in disguise, right?
∂24-May-89 1118 CL-Cleanup-mailer Issue: STREAM-CAPABILITIES
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 24 May 89 11:18:00 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 600016; 24 May 89 13:28:33 EDT
Date: Wed, 24 May 89 13:32 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STREAM-CAPABILITIES
To: chapman%aitg.DEC@decwrl.dec.com
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <8905241309.AA12009@decwrl.dec.com>
Message-ID: <19890524173228.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
[Added back the CL-Cleanup mailing list]
Date: 24 May 89 06:28
From: chapman%aitg.DEC@decwrl.dec.com
> Add the following function:
>
> INTERACTIVE-STREAM-P stream
>
> Returns T if the stream is interactive, otherwise NIL. Signals
> an error of type TYPE-ERROR if the argument is not a stream.
I thought that in most cases, if the argument to a function is not
of the right type, the results are unspecified, but if the implementation
were to signal an error, it would be of type TYPE-ERROR. Why is this
one different?
I was under the impression that most functions "signal an error" for
wrong type arguments, except for some that "should signal an error" for
efficiency reasons, and some that "might signal an error" for implementation
flexibility reasons. Clearly neither of those reasons applies to
INTERACTIVE-STREAM-P, which need not be extra fast and is not tightly
coupled to implementation data or control structures. Hence I proposed
it in the "signals an error" category.
Also, I think the "definition" of interactive later in this proposal is
too vague to be portably useful, unless, in the spec, we change the
wording from "Some examples of..." to "If a stream is... then it is
interactive" or something like that.
It's not possible to make a specific definition of "interactive" that
applies to all operating systems, I concluded from earlier discussion.
However, "everyone knows" appoximately what it means. Hence the idea
of describing it by example rather than defining it.
Would it be better to take this alternate, minimalist approach:
INTERACTIVE-STREAM-P stream
If the argument is a stream, returns T or NIL at the discretion of the
implementation and its underlying operating system. The general intent
is to distinguish between interactive and batch (or background or
command-file) operations.
Signals an error of type TYPE-ERROR if the argument is not a stream.
*TERMINAL-IO* might or might not be interactive.
∂24-May-89 1334 CL-Cleanup-mailer Re: Issue: PATHNAME-LOGICAL (version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 24 May 89 13:34:49 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 600216; 24 May 89 16:36:42 EDT
Date: Wed, 24 May 89 16:40 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-LOGICAL (version 2)
To: Gail Zacharias <gz@spt.entity.com>
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <CMM.0.88.612031932.gz@spt.entity.com>
Message-ID: <19890524204040.0.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Date: Wed, 24 May 1989 12:52:12 EDT
From: Gail Zacharias <gz@spt.entity.com>
I noticed Coral (Macintosh Allegro Common Lisp) has a logical pathname
feature which is somewhat simpler but aimed at solving the same problems.
In particular your feature only affects the directory component and does
not allow wildcard mapping, only one-to-one mapping. Should we say
something about this in the current practice section?
I really like this, except that I have a problem with the syntax - it looks
too much like the Macintosh pathname syntax. A name like "pcl:foo.lisp" can
be parsed as either a physical Macintosh pathname or a logical pathname. I
realize that the proposal is unambiguous on this point, resolving it in favor
of a logical pathname. But this means that a program defining a logical "pcl"
host thereby makes impossible for the user to access files on his physical
"pcl" disk. Note that TOPS-20, VMS and (I think) MSDOS have a similar
problem.
The use of colon affects Symbolics more than anybody, since logical
pathname host names conflict with network host names, whereas on the
Macintosh and those DEC and IBM systems they only conflict with device
names, usually a much smaller set and often chosen with names that are
distinctive enough that conflict is unlikely. We thought about this but
no matter what syntax we choose it's going to be a conflict for
somebody. We can't even use double colon without conflict since DEC is
already using it.
I could make the alternate argument that the use of colon fits really
nicely into the Macintosh environment, where hd: means the hard disk,
carry: means the floppy disk used for taking stuff between machines, and
pcl: means the logical disk with PCL on it. Does that make sense to
you? I could also point out that the Macintosh already allows you to
have two volumes with the same name and (usually!) provides mechanisms
(such as the Drive button in the Standard File dialog) to allow you
to disambiguate.
How about using "!" as the host separator?
That's current practice in Coral (except I gather you currently throw
away the host and don't do anything with it), but might be considered
poor in the standard since ! is one of the characters that Common Lisp
has been careful not to use for anything and leave for the users.
Another thing we could do is to make logical pathname namestrings
more distinctive; instead of starting with a word that has been defined
as a logical pathname host name, they could start with some character.
However, I have been unable to think of any character that would not
conflict with existing use in some file system.
I'm amenable to alternative syntax suggestions. I'll be surprised if
anyone comes up with a good one, though, since this has been explored
before without success. I think we just have to grab some syntactic
space for logical pathnames.
The other thing we could do is not standardize logical pathname
namestrings at all, but require some other construct to be used, perhaps
a make-pathname call or a new function (logical-pathname "string"). I
think that would be very ugly and I'd like to avoid it.
∂24-May-89 2338 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 24 May 89 23:38:21 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 24 MAY 89 23:34:28 PDT
Date: 24 May 89 23:34 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (version 4)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Tue, 23 May 89 13:19 EDT
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@sail.stanford.edu
Message-ID: <890524-233428-10964@Xerox>
The problem description is convincing. I'm still not personally convinced
that this is the "best" solution to the problem, or that all aspects of the
problem are as bad as others.
I think it is intolerable that different implementations talk about the
*same* file system in different ways. I'm less certain that making things
portable across Tops-20 and Unix and DOS is as important, and warrents the
extra mechanism of additional keywords & arguments. However, I don't feel
too strongly about it.
∂24-May-89 2338 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-VALUE (version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 24 May 89 23:38:25 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 24 MAY 89 23:38:03 PDT
Date: 24 May 89 23:37 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-COMPONENT-VALUE (version 2)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Tue, 23 May 89 13:20 EDT
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@sail.stanford.edu
Message-ID: <890524-233803-10977@Xerox>
I wish "other implementations were not surveyed" were not true. Will "other
implementations" speak up? My quick glance at this didn't turn up anything
too serious, except the risk of overspecifying based on limited experience.
∂25-May-89 1108 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (version 4)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 25 May 89 11:08:50 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA11153; Thu, 25 May 89 12:09:05 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA09121; Thu, 25 May 89 12:09:01 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8905251809.AA09121@defun.utah.edu>
Date: Thu, 25 May 89 12:08:59 MDT
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (version 4)
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@sail.stanford.edu, sandra%defun@cs.utah.edu,
gray@dsg.csc.ti.com
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 23 May 89 13:19 EDT
I have a number of comments on this writeup, and some general comments
on the issue it's trying to deal with.
First the specific ones.
> Issues of alphabetic case in pathnames are a major source of problems.
I'd say it's a much less "major" source of problems than issues
relating to what characters may appear in pathname components and the
length of various components.
> There are two kinds of pathname case portability problems: moving
> programs from one Common Lisp to another, and moving pathname component
> values from one file system to another. To solve the first problem, all
> Common Lisp implementations that support a particular file system must
> use compatible representations for pathname component values. To solve
> the second problem, there must be a common representation for the least
> common denominator pathname component values that exist on all
> interesting file systems.
Since this proposal doesn't do either of these two things, I don't
understand what this paragraph is doing in this writeup.
> :COMMON means those strings follow this common convention:
> - all uppercase means to use a file system's customary case.
> - all lowercase means to use the opposite of the customary case.
> - mixed case represents itself.
> The second and third bullets exist so that translation from local to
> common and back to local is information-preserving.
I don't understand the motivation for this. There is no way to
specify a pathname component that is literally all uppercase or all
lowercase.
> VAX/VMS is upper-case-only, so it translates common to local by upcasing,
> and translates local to common with no change.
VAX/VMS is case-insensitive but its canonical case is uppercase. Its
file system primitives are perfectly capable of dealing with lowercase
namestrings -- it's just that if you ever ask it for the name of a
file, it will return it in uppercase.
Now for the more general comments. I think that the :CASE :COMMON
option is pretty much useless because it doesn't handle the situation
where you want the pathname component kept in exactly the case you
specified it. I can't imagine any reason why I would want to specify
a pathname component in the *opposite* of canonical case, plus if I
did I could get it by inverting the canonical case.
I'd suggest trashing the current proposal and instead adding a
:CANONICALIZE keyword argument to MAKE-PATHNAME and PARSE-NAMESTRING.
A value of T indicates that the implementation is free to canonicalize
the representation of the pathname component in any way that is
appropriate for the particular host. This might include things like
truncation and performing some kind of filtering or translation on
invalid characters, and even expansion of logical names (on VMS), as
well as case conversion.
A value of NIL indicates that the pathname components are to be
treated as literals. I think it would be a good idea to require an
error to be signalled in situations where a component is not a
legitimate value.
I think implementations should be permitted to assign meanings for
other values of this argument.
-Sandra
-------
∂25-May-89 1130 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-VALUE (version 2)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 25 May 89 11:30:11 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA11868; Thu, 25 May 89 12:30:31 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA09139; Thu, 25 May 89 12:30:29 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8905251830.AA09139@defun.utah.edu>
Date: Thu, 25 May 89 12:30:28 MDT
Subject: Re: Issue: PATHNAME-COMPONENT-VALUE (version 2)
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@sail.stanford.edu, sandra%defun@cs.utah.edu,
gray@dsg.csc.ti.com
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 23 May 89 13:20 EDT
As I've said before, I don't think that trying to construct or pick
apart pathnames by component can be accomplished portably in any case,
because even if you restrict the representation of what can appear in
the various components, the objects you stuff in may or may not make
sense for a particular file system. Instead, I would much prefer to
deprecate MAKE-PATHNAME and the PATHNAME-xxx accessors and leave the
question of representation of components unspecified in the standard.
I realize that this position may be seen as being too extreme. In
that case I'd be willing to shut up and go along with proposal SPECIFY
as long as my position gets noted in the writeup.
-Sandra
-------
∂25-May-89 1239 CL-Cleanup-mailer Re: Issue: PATHNAME-LOGICAL (version 2)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 25 May 89 12:39:37 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA19949; Thu, 25 May 89 13:39:57 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA09185; Thu, 25 May 89 13:39:54 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8905251939.AA09185@defun.utah.edu>
Date: Thu, 25 May 89 13:39:52 MDT
Subject: Re: Issue: PATHNAME-LOGICAL (version 2)
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@sail.stanford.edu, sandra%defun@cs.utah.edu,
gray@dsg.csc.ti.com
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 23 May 89 13:21 EDT
I have a number of problems with this proposal...
I don't understand why there's any need for magic numbers (12 and 6)
and restrictions on what characters may appear in a logical pathname
component. The rationale says this is an arbitrary decision, but
doesn't address the question of why restrictions are necessary at all.
The proposal mentions that not all filesystems support versions and
that versions in logical pathnames can't be used portably. More
generally, not all filesystems have notions of hosts, devices,
directories, and file types either. (In other words, about the only
thing you can depend on a filename always having is a name.) Why treat
versions as a special case, but ignore all the other problems?
How are functions like OPEN supposed to map a logical pathname onto a real
pathname? (Does it do it in the same way as TRANSLATE-LOGICAL-PATHNAME or
can it use some other mapping?)
The dependence on issue PATHNAME-WILD (the functions PATHNAME-MATCH-P
and TRANSLATE-PATHNAME that are referenced in the description of
TRANSLATE-LOGICAL-PATHNAME) ought to be made more explicit. What
happens if PATHNAME-WILD fails?
LOAD-LOGICAL-PATHNAME-TRANSLATIONS sounds suspiciously like REQUIRE --
I'm sure that's a bad sign...
COMPILE-FILE-PATHNAME doesn't seem to have anything to do with the
rest of this proposal.
In general, I don't really see what this proposal buys the user that
can't already be achieved using other mechanisms that are already part
of the language. For example, when I have some files that live in
different places on different hosts, I usually put a pathname
containing the appropriate pathname for that place in a variable and
call MERGE-PATHNAMES to get the full pathnames of the individual
files. Logical pathnames don't eliminate the necessity of having
literal, host-specific pathnames in a program; you still have to
supply them to DEFINE-LOGICAL-PATHNAME-TRANSLATIONS.
-Sandra
-------
∂25-May-89 1245 CL-Cleanup-mailer Re: Issue: PATHNAME-SYSTEM-TYPE (version 1)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 25 May 89 12:45:12 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA21098; Thu, 25 May 89 13:45:33 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA09195; Thu, 25 May 89 13:45:31 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8905251945.AA09195@defun.utah.edu>
Date: Thu, 25 May 89 13:45:29 MDT
Subject: Re: Issue: PATHNAME-SYSTEM-TYPE (version 1)
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@sail.stanford.edu, sandra%defun@cs.utah.edu,
gray@dsg.csc.ti.com
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 23 May 89 14:06 EDT
I don't have any big objection to this proposal but I've never had any
pressing need for anything like this either. I guess I would probably
vote against it unless somebody can argue that it really offers necessary
functionality, on the general principle of opposing adding things to the
language just because they seem hypothetically "plausible".
-Sandra
-------
∂25-May-89 1249 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-VALUE (version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 25 May 89 12:49:02 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 600733; 25 May 89 12:01:12 EDT
Date: Thu, 25 May 89 12:05 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-COMPONENT-VALUE (version 2)
To: masinter.pa@Xerox.COM
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <890524-233803-10977@Xerox>
Message-ID: <19890525160515.6.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Line-fold: No
Date: 24 May 89 23:37 PDT
From: masinter.pa@Xerox.COM
I wish "other implementations were not surveyed" were not true.
Me too.
Will "other implementations" speak up?
I do not have convenient access to most Common Lisp implementations, so
I was hoping to rely on the other members of the Cleanup committee, who
together cover a pretty broad range of systems, to supply current
practice information before the issue is forwarded to X3J13 as a whole.
This applies to all of the pathname issues. Please help, y'all.
∂25-May-89 1249 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 25 May 89 12:49:25 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 600887; 25 May 89 14:50:34 EDT
Date: Thu, 25 May 89 14:54 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (version 4)
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: CL-Cleanup@sail.stanford.edu, gray@dsg.csc.ti.com
In-Reply-To: <8905251809.AA09121@defun.utah.edu>
Message-ID: <19890525185426.6.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Date: Thu, 25 May 89 12:08:59 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
I have a number of comments on this writeup, and some general comments
on the issue it's trying to deal with.
First the specific ones.
> Issues of alphabetic case in pathnames are a major source of problems.
I'd say it's a much less "major" source of problems than issues
relating to what characters may appear in pathname components and the
length of various components.
Let's not quibble about this, it's unproductive.
> There are two kinds of pathname case portability problems: moving
> programs from one Common Lisp to another, and moving pathname component
> values from one file system to another. To solve the first problem, all
> Common Lisp implementations that support a particular file system must
> use compatible representations for pathname component values. To solve
> the second problem, there must be a common representation for the least
> common denominator pathname component values that exist on all
> interesting file systems.
Since this proposal doesn't do either of these two things, I don't
understand what this paragraph is doing in this writeup.
This proposal does the alphabetic case portion of both things. Do you
think it doesn't? Or are you saying that you would prefer to see all the
pathname issues rolled into one omnibus proposal? I was hesitant about
not allowing people the chance to vote separately on each portion of the
pathname stuff.
> :COMMON means those strings follow this common convention:
> - all uppercase means to use a file system's customary case.
> - all lowercase means to use the opposite of the customary case.
> - mixed case represents itself.
> The second and third bullets exist so that translation from local to
> common and back to local is information-preserving.
I don't understand the motivation for this. There is no way to
specify a pathname component that is literally all uppercase or all
lowercase.
That is correct, in the :COMMON representation there is no way to say
those things. That's because those are not portable concepts. You use
the :LOCAL representation to do things like that.
Things would be a lot simpler if :COMMON representation was monocase,
which is the least common denominator. The problem with that would be
that in some file systems (e.g. Unix) there would be many pathnames
that could not be represented in :COMMON representation at all. Rather
than signal an error when such a pathname is encountered, it seems better
to assign otherwise unused characters (the lowercase letters) to represent
such pathnames. Perhaps the proposal should be reworked to present things
in these terms?
> VAX/VMS is upper-case-only, so it translates common to local by upcasing,
> and translates local to common with no change.
VAX/VMS is case-insensitive but its canonical case is uppercase. Its
file system primitives are perfectly capable of dealing with lowercase
namestrings -- it's just that if you ever ask it for the name of a
file, it will return it in uppercase.
That's precisely what upper-case-only means. Sorry about the
terminological unclarity. Upper-case-only wasn't intended to mean
that it signals an error if you give it a lowercase letter; I don't
think we want any file systems like that in Common Lisp; if the file
system doesn't upcase, the Lisp interface to it should, rather than
signalling an error if it can't handle lower case. Should I augment
the proposal with more definitions of terminology?
Note how VAX/VMS differs from other case-insensitive systems such
as the Macintosh, where file lookup is case-insensitive but if you
ask for the name of a file it will give it back in the same alphabetic
case in which you created it.
Now for the more general comments. I think that the :CASE :COMMON
option is pretty much useless because it doesn't handle the situation
where you want the pathname component kept in exactly the case you
specified it.
That's what :CASE :LOCAL is for. :CASE :COMMON is for portable programs
that want to conform to the local conventions of the local file system
rather than imposing their own conventions. Not all programs want to do
that, but I would hardly characterize that as useless.
I can't imagine any reason why I would want to specify
a pathname component in the *opposite* of canonical case, plus if I
did I could get it by inverting the canonical case.
I can't imagine any reason either. See above for the motivation for this.
I'd suggest trashing the current proposal and instead adding a
:CANONICALIZE keyword argument to MAKE-PATHNAME and PARSE-NAMESTRING.
A value of T indicates that the implementation is free to canonicalize
the representation of the pathname component in any way that is
appropriate for the particular host. This might include things like
truncation and performing some kind of filtering or translation on
invalid characters, and even expansion of logical names (on VMS), as
well as case conversion.
A value of NIL indicates that the pathname components are to be
treated as literals. I think it would be a good idea to require an
error to be signalled in situations where a component is not a
legitimate value.
I think implementations should be permitted to assign meanings for
other values of this argument.
This could be a useful feature in its own right, but note that it is
no help at all for retrieving pathname components in a form that is
independent of the local file system, which is what the :CASE argument
to the PATHNAME-xxx accessors proposed here is for. I would encourage
you to write up your proposal in more detail. I think you will find
some difficulties in defining exactly what is an invalid character
(for example, is a character invalid if this file system uses it as
a wildcard character but other file systems use it as an ordinary
character?) and some of the other specifics. Also it would be helpful
to see your proposal complete with rationale, examples, costs, and
benefits.
∂25-May-89 1251 CL-Cleanup-mailer Re: Issue: PATHNAME-SUBDIRECTORY-LIST (version 6)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 25 May 89 12:51:43 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA22772; Thu, 25 May 89 13:52:04 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA09203; Thu, 25 May 89 13:52:00 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8905251952.AA09203@defun.utah.edu>
Date: Thu, 25 May 89 13:51:59 MDT
Subject: Re: Issue: PATHNAME-SUBDIRECTORY-LIST (version 6)
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@sail.stanford.edu, sandra%defun@cs.utah.edu,
gray@dsg.csc.ti.com
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 23 May 89 13:22 EDT
The comments I made on issue PATHNAME-COMPONENT-VALUE also apply here.
In particular, I'm not personally motivated to add such a feature
because I've never had any need to manipulate hierarchical directories
from within a Common Lisp program. Any program that does so is
necessarily nonportable.
-Sandra
-------
∂25-May-89 1258 CL-Cleanup-mailer Issue: FLOAT-UNDERFLOW (version 2)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 25 May 89 12:58:31 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA01118g; Thu, 25 May 89 12:57:31 PDT
Received: by bhopal id AA16095g; Thu, 25 May 89 12:57:13 PDT
Date: Thu, 25 May 89 12:57:13 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8905251957.AA16095@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Wed, 24 May 89 13:23 EDT <19890524172312.2.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Subject: Issue: FLOAT-UNDERFLOW (version 2)
re: [Lucid's WITH-FLOATING-POINT-TRAPS]
The inability to converge on a design for such an elaborate feature is
precisely the reason for proposing the very simple feature.
The design may not be as elaborate or complex as you think. When you see
the synopsis of it below, I think you'll have to agree that a simple setting
of an implementation-dependent parameter yields the functionality of
WITHOUT-FLOATING-UNDERFLOW-TRAPS with only two differences:
(1) the syntax is superficially different
(2) the equivalent of WITH-FLOATING-UNDERFLOW-TRAPS comes
along with it.
So an implementation wanting to obey the WITH-FLOATING-POINT-TRAPS interface,
but having already implemented WITHOUT-FLOATING-UNDERFLOW-TRAPS, could in
fact support the former by a simple use of the latter.
re: Also note that underflow is the _only_ exception that some applications
have a very strong need to enable while at the same time other applications
have a very strong need to disable. Thus just the simple feature gets
us most of the way towards perfection.
So why are these "some" applications so much more worthy than the others
that "have a very strong need" to selectively enable and disable the
overflow trap? [Using ieee floating-point, it is very useful at times to
admit positive and negative infinity representations, which is what the
untrapped overflow gives you].
What makes me a bit leary of this proposal, at this stage of the game,
is that I thought we had agreed to close down Cleanup for new proposals,
in order to concentrate our efforts of finishing the large amount of
work already started but not completed. For things previously discussed,
and which are clearly non-controversial, I see no problem. Now, the issue
of floating-point extremals was discussed briefly after I brought up the
issue of denormalization (over a year ago?), and got replies from Cassels
at Symbolics.com, Steele at Think.com and Hilfinger at Berkeley.edu
[that discussion might have been on Common-Lisp@SAIL rather than on
CL-Cleanup@SAIL]; at least it seemed there was consensus on that matter.
But the larger picture of treatment of floating-point traps just didn't
get discussed.
Anyway, before formalizing a CLeanup proposal [which I fear would be
moot at this late a date], let me get your reactions to a description
of the relevant features from Lucid Common Lisp:
(1) SUPPORTED-FLOATING-POINT-CONDITIONS -- An implementation-dependent
defconstant which typically varies from port to port; holds the list
of conditions which __can be__ supported as floating-point traps.
These are all condition names in the (extended) error system. For
example, ports using the MC68881 chip typically have:
floating-point-inexact
floating-point-overflow
floating-point-underflow
floating-point-OutOfDomain
floating-point-NaN
floating-point-UnorderedComparison
division-by-zero
Other ports might have only division-by-zero, floating-point-underflow,
and floating-point-overflow. Frequently these are continuable
conditions, but that varies with the degree of difficulty in restarting
a floating-point co-processor.
(2) ENABLED-FLOATING-POINT-TRAPS -- A function of no arguments which
Returns a list of all the floating-point condition names currently
enabled for error trapping. These names will be a subset of those
on SUPPORTED-FLOATING-POINT-CONDITIONS. A SETF method is provided
for this function as the means of explicitly setting the traps. [Of
course, certain software functions need to inspect the established
state too -- it isn't merely a blind poking of the control register
of a floating point chip.]
(3) WITH-FLOATING-POINT-TRAPS -- a macro for temporary setting of floating
point trapping conditions [typically, the temporary setting of traps
can be done in an implementation-dependent way that is much more
efficient than just saving and restoring (ENABLED-FLOATING-POINT-TRAPS)]
(defmacro with-floating-point-traps ((enable-list disable-list) &body body)
....)
where the 'enable-list' and 'disable-list' are evaluated. The traps
enabled during the execution of the body are:
(UNION <enable-list>
(SET-DIFFERENCE (ENABLED-FLOATING-POINT-TRAPS) <disable-list>))
Sample uses might be:
(with-floating-point-traps
('(floating-point-underflow)
supported-floating-point-conditions)
...
... ;all floating-point traps turned off except underflow
...)
(with-floating-point-traps
('()
'(floating-point-underflow))
...
... ;underflow turned off; all others left alone.
...)
I would expect controversy about the syntax of WITH-FLOATING-POINT-TRAPS;
and I would expect that someone would want to waste our time arguing how
much detail we would need in the specification of the defconstant
SUPPORTED-FLOATING-POINT-CONDITIONS.
-- JonL --
∂25-May-89 1303 CL-Cleanup-mailer Issue: STREAM-CAPABILITIES (version 3), or Issue: MAP-INTO (version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 25 May 89 13:03:49 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA01143g; Thu, 25 May 89 13:01:17 PDT
Received: by bhopal id AA16119g; Thu, 25 May 89 13:00:59 PDT
Date: Thu, 25 May 89 13:00:59 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8905252000.AA16119@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Wed, 24 May 89 13:49 EDT <19890524174912.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: STREAM-CAPABILITIES (version 3), or Issue: MAP-INTO (version 1)
re: This is really a reply to Moon's MAP-INTO proposal in disguise, right?
Oh, gleep, yes. My apologies.
-- JonL --
∂25-May-89 1306 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (version 6)
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 25 May 89 13:05:52 PDT
Received: from fafnir.think.com by Think.COM; Thu, 25 May 89 16:04:45 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Thu, 25 May 89 16:04:14 EDT
Received: from joplin.think.com by verdi.think.com; Thu, 25 May 89 16:04:00 EDT
From: Guy Steele <gls@Think.COM>
Received: by joplin.think.com; Thu, 25 May 89 16:03:57 EDT
Date: Thu, 25 May 89 16:03:57 EDT
Message-Id: <8905252003.AA10059@joplin.think.com>
To: sandra%defun@cs.utah.edu
Cc: Moon@stony-brook.scrc.symbolics.com, CL-Cleanup@sail.stanford.edu,
sandra%defun@cs.utah.edu, gray@dsg.csc.ti.com
In-Reply-To: Sandra J Loosemore's message of Thu, 25 May 89 13:51:59 MDT <8905251952.AA09203@defun.utah.edu>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (version 6)
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Date: Thu, 25 May 89 13:51:59 MDT
The comments I made on issue PATHNAME-COMPONENT-VALUE also apply here.
In particular, I'm not personally motivated to add such a feature
because I've never had any need to manipulate hierarchical directories
from within a Common Lisp program. Any program that does so is
necessarily nonportable.
I'm sorry, but I disagree with your last sentence. A program that
*insists* on using hierarchical directories may be nonportable,
but a program that is *prepared* to deal with them if the local
file system happens to contain them is not necessarily nonportable,
and indeed may me more portable than a program thast insists on
dealing with directories in a nonhierarchical manner.
--Guy
∂25-May-89 1306 CL-Cleanup-mailer Re: Issue: PATHNAME-WILD (version 5)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 25 May 89 13:06:09 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA24402; Thu, 25 May 89 14:06:29 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA09216; Thu, 25 May 89 14:06:20 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8905252006.AA09216@defun.utah.edu>
Date: Thu, 25 May 89 14:06:18 MDT
Subject: Re: Issue: PATHNAME-WILD (version 5)
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@sail.stanford.edu, sandra%defun@cs.utah.edu,
gray@dsg.csc.ti.com
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 23 May 89 13:24 EDT
I don't have any big objection to the functionality being proposed here,
but again it's something I've never needed myself so I'm not real
motivated about adding it to the language.
I don't understand what all the arguments to TRANSLATE-PATHNAME are
for. I guess that this function is intended to be a merging operation
that fills in wildcard components in one pathname with matching
components from another pathname, but I don't understand why you need
to pass in two wildcard pathnames instead of one, or what
reversibility really implies. I got kind of lost reading the
description of this function -- isn't there a more concise way to
state what is going on?
-Sandra
-------
∂25-May-89 1343 CL-Cleanup-mailer Issue: FLOAT-UNDERFLOW (version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 25 May 89 13:43:27 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 601047; 25 May 89 16:45:15 EDT
Date: Thu, 25 May 89 16:49 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FLOAT-UNDERFLOW (version 2)
To: Jon L White <jonl@lucid.com>
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <8905251957.AA16095@bhopal>
Message-ID: <19890525204907.5.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Date: Thu, 25 May 89 12:57:13 PDT
From: Jon L White <jonl@lucid.com>
....
What makes me a bit leary of this proposal, at this stage of the game,
is that I thought we had agreed to close down Cleanup for new proposals,
in order to concentrate our efforts of finishing the large amount of
work already started but not completed.
Agreed. Let me explain my purpose in bringing up now these new issues
like FLOAT-UNDERFLOW (the pathnames ones are not new, although one of
them had not been written up before). I want to get a decision on whether
these things are going to be in or out of ANSI Common Lisp. If they are
out, I am not going to have a tantrum, it just means my efforts should be
redirected towards a de facto standard rather than a de jure standard.
Of course if ANSI Common Lisp doesn't address these issues, that will make
it a worse language than it would be otherwise, but we already know that
ANSI Common Lisp is not going to be a perfect language, and we assume we
all had accepted that in our hearts quite a long time ago or we wouldn't
still be working on it.
The CL-Cleanup committee could make a decision never to show these issues
to X3J13 and I wouldn't have a tantrum over that either. You're saying
that FLOAT-UNDERFLOW is best not brought up at this time, and I think that
is a reasonable position to take (although I don't know whether I myself
agree with it, since I haven't read your sketch of a proposal yet).
There are a number of other issues that I decided on my own not to bring
up with CL-Cleanup at all, since they are clearly inappropriate to
propose at this late date for the current de jure standard, even though
they are clearly issues that a language with the goals of ANSI Common
Lisp ought to address. I'd rather not distract you by listing those
issues right now.
Comments on the specifics of your proposal later.
∂25-May-89 1350 CL-Cleanup-mailer Re: Issue: PATHNAME-SYSTEM-TYPE (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 25 May 89 13:50:01 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 601062; 25 May 89 16:51:26 EDT
Date: Thu, 25 May 89 16:55 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-SYSTEM-TYPE (version 1)
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: CL-Cleanup@sail.stanford.edu, gray@dsg.csc.ti.com
In-Reply-To: <8905251945.AA09195@defun.utah.edu>
Message-ID: <19890525205530.1.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Date: Thu, 25 May 89 13:45:29 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
I don't have any big objection to this proposal but I've never had any
pressing need for anything like this either.
Since you're the one who says that pathname manipulating programs are
best written by getting namestrings and doing string processing on
them, can you tell me how your programs know what syntax to expect
in the namestrings? That's what this proposal was intended to address,
so if there is some other way to do that that's adequate, perhaps we
don't need this proposal.
∂25-May-89 1438 CL-Cleanup-mailer Re: Issue: PATHNAME-SYSTEM-TYPE (version 1)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 25 May 89 14:38:13 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA29401; Thu, 25 May 89 15:38:28 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA09323; Thu, 25 May 89 15:38:25 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8905252138.AA09323@defun.utah.edu>
Date: Thu, 25 May 89 15:38:24 MDT
Subject: Re: Issue: PATHNAME-SYSTEM-TYPE (version 1)
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
CL-Cleanup@sail.stanford.edu, gray@dsg.csc.ti.com
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Thu, 25 May 89 16:55 EDT
> Date: Thu, 25 May 89 16:55 EDT
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>
> Since you're the one who says that pathname manipulating programs are
> best written by getting namestrings and doing string processing on
> them, can you tell me how your programs know what syntax to expect
> in the namestrings?
I've never said anything like that and I think it's a crummy idea
anyway. What I *have* said is that the only pathname operations that
a portable program can expect to do that make sense on all file
systems are:
1. Convert a (file-system specific) namestring to a pathname, and vice
versa. The namestring need not appear as a literal in the program or
be manipulated by doing string processing -- for example, you might
ask the user of the application to type in a namestring or supply
one as an argument. That's what applications written in other
programming languages such as C typically do, and there's really nothing
wrong with it because users of the application certainly know what
kind of file system their files live on.
2. Test whether an object is a pathname.
3. Merge two pathnames to fill in missing components. This is the whole
point, in my view, of having pathnames at all, and where Common Lisp
wins over C -- there is a library function to do this instead of
programmers having to write their own, nonportable string-manipulation
code to do this.
The point I've been trying to make is that any program that tries to
construct pathnames by providing component values directly is bound to
run into portability problems. The file system may not support the
concept of a particular pathname component at all. The file system
may impose limitations on the length of the component or on what
characters may appear in it. (The perverse example I've cited before
is Cray's CTSS operating system, where files are limited to
6-character names, and there is no concept of hosts, devices,
directories, types, or versions.) Components extracted from another
pathname may not make sense in a new pathname being constructed for a
different host. That's why I think the right solution is really to
deprecate MAKE-PATHNAME.
Specifying what *might* appear in a pathname component does not fix
the fundamental nonportability of MAKE-PATHNAME, because programmers
have no way of knowing whether an object which *might* be a valid
component actually *will be* a valid component in the environment in
which the application is run.
-Sandra
-------
∂25-May-89 1458 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-VALUE (version 2)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 25 May 89 14:58:40 PDT
Received: by ti.com id AA20849; Thu, 25 May 89 16:56:53 CDT
Received: from dsg by tilde id AA04070; Thu, 25 May 89 16:37:46 CDT
Received: From Kelvin By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 25 May 89 11:28:28 CDT
Message-Id: <2821105757-10704406@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 25 May 89 11:29:17 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: masinter.pa@Xerox.COM,
"David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@sail.stanford.edu
Subject: Re: Issue: PATHNAME-COMPONENT-VALUE (version 2)
In-Reply-To: Msg of 24 May 89 23:37 PDT from masinter.pa@Xerox.COM
> I wish "other implementations were not surveyed" were not true. Will "other
> implementations" speak up?
Like Genera, the Explorer current practice is to use an object instead of
a string for the host component. The directory component is a list of
strings, not yet supporting the symbols specified in proposal
PATHNAME-SUBDIRECTORY-LIST; other than that, the Explorer conforms to
proposal PATHNAME-COMPONENT-VALUE:SPECIFY.
∂25-May-89 1504 CL-Cleanup-mailer Re: Issue: PATHNAME-SYSTEM-TYPE (version 1)
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 25 May 89 15:04:38 PDT
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA07438; Thu, 25 May 89 18:05:01 -0400
Received: from localhost by mist. (4.0/SMI-4.0)
id AA09189; Thu, 25 May 89 18:04:49 EDT
Message-Id: <8905252204.AA09189@mist.>
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Cc: CL-Cleanup@sail.stanford.edu
Subject: Re: Issue: PATHNAME-SYSTEM-TYPE (version 1)
In-Reply-To: Your message of Thu, 25 May 89 15:38:24 -0600.
<8905252138.AA09323@defun.utah.edu>
Date: Thu, 25 May 89 18:04:46 EDT
From: Dan L. Pierson <pierson@mist.encore.com>
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Date: Thu, 25 May 89 15:38:24 MDT
The point I've been trying to make is that any program that tries to
construct pathnames by providing component values directly is bound to
run into portability problems. The file system may not support the
concept of a particular pathname component at all. The file system
may impose limitations on the length of the component or on what
characters may appear in it. (The perverse example I've cited before
is Cray's CTSS operating system, where files are limited to
6-character names, and there is no concept of hosts, devices,
directories, types, or versions.) Components extracted from another
pathname may not make sense in a new pathname being constructed for a
different host. That's why I think the right solution is really to
deprecate MAKE-PATHNAME.
But if we restricted what Common Lisp supports to what is possible in
the most restrictive existing environment we wouldn't have modern Lisp
at all.
There are a large number of widely used operating systems that shared
a set of features including hierarchical directories, hosts, types,
and sort of reasonable file name length limits. These systems include
several Unix's, VMS, MS-DOS, OS/2, Mac OS, TOPS-20, Genera, etc. If I
can write a program that uses these file name features in a way that
is portable across all of these systems without even having to know
the idiosyncratic syntax of the less familiar systems, I'll be a very
happy user. The fact that my program will not run on CTSS, SCOPE,
DOS/360, etc. won't bother me very much.
I doubt that many new general purpose file systems are being designed
without the basic feature set required by these facilities. Since we
are standardizing a language for future use, I suggest that we should
worry more about easing portable programming in the systems that we
_will_ be using than complaining that it's impossible to paper over
all of the differences between obsolete systems.
∂25-May-89 1524 CL-Cleanup-mailer Re: Issue: PATHNAME-SYSTEM-TYPE (version 1)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 25 May 89 15:24:20 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA00850; Thu, 25 May 89 16:24:39 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA09361; Thu, 25 May 89 16:24:37 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8905252224.AA09361@defun.utah.edu>
Date: Thu, 25 May 89 16:24:36 MDT
Subject: Re: Issue: PATHNAME-SYSTEM-TYPE (version 1)
To: Dan L. Pierson <pierson@mist.encore.com>
Cc: sandra%defun@cs.utah.edu (Sandra J Loosemore),
CL-Cleanup@sail.stanford.edu
In-Reply-To: Dan L. Pierson <pierson@mist.encore.com>, Thu, 25 May 89 18:04:46 EDT
> Date: Thu, 25 May 89 18:04:46 EDT
> From: Dan L. Pierson <pierson@mist.encore.com>
>
> But if we restricted what Common Lisp supports to what is possible in
> the most restrictive existing environment we wouldn't have modern Lisp
> at all.
Hey, that's my argument! Issue PATHNAME-COMPONENT-CASE even says that
this is the end goal -- to come up with the least common denominator
for pathname component values. I think it's the wrong goal, precisely
because the least common denominator (at least as far as MAKE-PATHNAME
is concerned) isn't very useful.
I think we'd be better off sidestepping the whole issue and simply
putting some discussion in the standard about what kinds of pathname
operations are portable, and which aren't. In the absence of such a
discussion in CLtL, I've seen users (even experienced Lisp
implementors, not just students) make assumptions in their programs
that inhibit portability without realizing they've done so.
-Sandra
-------
∂25-May-89 1557 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (version 4)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 25 May 89 15:56:21 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA02018; Thu, 25 May 89 16:56:37 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA09378; Thu, 25 May 89 16:56:35 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8905252256.AA09378@defun.utah.edu>
Date: Thu, 25 May 89 16:56:34 MDT
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (version 4)
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
CL-Cleanup@sail.stanford.edu, gray@dsg.csc.ti.com
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Thu, 25 May 89 14:54 EDT
> Date: Thu, 25 May 89 14:54 EDT
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>
> I don't understand the motivation for this. There is no way to
> specify a pathname component that is literally all uppercase or all
> lowercase.
>
> That is correct, in the :COMMON representation there is no way to say
> those things. That's because those are not portable concepts. You use
> the :LOCAL representation to do things like that.
Have I misunderstood the proposal? I thought that the :LOCAL option
was supposed to indicate that the implementations should do whatever
case conversion that's appropriate for the local file system
regardless of the original case. If it's not supposed to do any
translation at all, perhaps it ought to be renamed to :NONE or
something more obvious.
> :CASE :COMMON is for portable programs that want to conform to the local
> conventions of the local file system rather than imposing their own
> conventions.
To me, it still seems like the decision is whether to canonicalize the
case or not, and that having the decision also depend on the case of
characters within the string is only needless complexity. I
understand your argument about the monocase pathnames, but I don't
think there's anything wrong with case canonicalization making some
filenames inaccessible. You simply specify that you don't want to
canonicalize the filename in such a situation.
> This could be a useful feature in its own right, but note that it is
> no help at all for retrieving pathname components in a form that is
> independent of the local file system, which is what the :CASE argument
> to the PATHNAME-xxx accessors proposed here is for.
I guess I'm confused about what problem this proposal is really trying
to address. Originally I thought that this proposal was just trying
to specify a mechanism for controlling whether the case of pathnames
are canonicalized, but now it looks like what you really want is some
way for pathnames to "remember" their original case even after they've
been canonicalized, so that when you extract the components and plug
them into some other pathname, you can get the original case back if
you ask for it. I just don't see how this is going to make it possible
to use MAKE-PATHNAME in a portable way.
-Sandra
-------
∂26-May-89 0842 CL-Cleanup-mailer Re: issue DYNAMIC-EXTENT-FUNCTION, version 1
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 26 May 89 08:42:38 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA25150; Fri, 26 May 89 09:42:55 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA09977; Fri, 26 May 89 09:42:52 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8905261542.AA09977@defun.utah.edu>
Date: Fri, 26 May 89 09:42:51 MDT
Subject: Re: issue DYNAMIC-EXTENT-FUNCTION, version 1
To: cl-cleanup@sail.stanford.edu
Cc: sandra%defun@cs.utah.edu
In-Reply-To: Jon L White <jonl@lucid.com>, Wed, 5 Apr 89 22:03:57 PDT
The last round of discussion on this issue was kind of inconclusive
and then I got distracted with some real work, but I have some time
now to work on a new version. It sounded like there was some support
for the idea of just extending the existing DYNAMIC-EXTENT declaration
to take arguments like (FUNCTION <x>) instead of adding another
declaration just for functions, so that'll probably be in the new
version unless somebody complains.
I don't know what to do about the related issue of declaring that an
anonymous lambda has dynamic extent -- none of the alternatives that
have come up so far have much appeal. Anyway, I don't think this
problem is as critical, because you could just restructure the program
to give the function a name. I think you'd also get the right effect
by declaring that all the closed-over variables and functions
referenced in the lambda have dynamic extent. So, I don't plan on
doing anything about it.
-Sandra
-------
∂26-May-89 0907 CL-Cleanup-mailer Issue: PATHNAME-LOGICAL (version 2)
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 May 89 09:04:47 PDT
Received: from ANNA-MAGDALENA-BACH.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 214133; Fri 26-May-89 12:03:53 EDT
Date: Thu, 25 May 89 13:12 EDT
From: "David A. Moon" <Moon@stony-brook.scrc.symbolics.com>
Subject: Issue: PATHNAME-LOGICAL (version 2)
To: Mly-lisp%mc.lcs.mit.edu@lcs.mit.edu
In-Reply-To: <19890525163809.5.MLY@JACKIE-O.AI.MIT.EDU>
Message-ID: <19890525171242.5.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Resent-To: CL-Cleanup@sail.stanford.edu
Resent-From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
Resent-Date: Fri, 26 May 89 12:03 EDT
Resent-Message-ID: <19890526160304.1.MLY@ANNA-MAGDALENA-BACH.AI.MIT.EDU>
Resent-Comments: My comments on PATHNAME-LOGICAL (Version 2)
I might not agree with all of your points here, but I think they
are well-taken. Do you mind if I forward this message to
CL-Cleanup or do you want to keep it private?
Date: Thu, 25 May 89 12:38 EDT
From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
1 I believe that mixing in the issue of parsing out host components from
pathname namestrings is a real mistake -- I hope it it grave enough to
kill this proposal (of the spirit of which I am otherwise extremely
supportive.)
To my thinking, a much better idea would be to define a new function, say,
(LOGICAL-PATHNAME <host-name> <namestring>) which would return a logical
pathname.
This has the advantage of not requiring that CL get into the business
of deciding whether hosts in general are found by
"HOST:" or "HOST::" or "/../HOST/" or whatever, and I think that this is
necessary in order to avoid huge confusion.
It has the disadvantage of not -specifying- a way for users to type
a logical pathname on a specific when being prompted by the system
(ie it doesn't specify the format of the string one must feed into the
PATHNAME function in order to get out a specific logical pathname.
It should be noted that CLtL is silent in general on what strings
produce what results from PATHNAME and I suspect it would be a mistake
to attempt to change this at this stage -- my extremely positive
experiences with symbolics' integrated and largely-consistent pathname
system notwithstanding.)
Note that -implementations- are free to specify some way of specifying
logical pathnames -- Symbolics' specification would be that one
specifies a string with a prefix of "Logical-Host-Name:"
2 My second problem is with the syntax of the pathnames.
I really think that this pseudo-ITSism has gone on long enough.
It has pissed me off for years that bolix logical pathnames don't
have the same basic syntax as LMFS and FEP pathnames (which after all
have the best of all possible syntaxes. I'm not joking!)
I note the rationale
``The choice of logical pathname syntax was guided by the goal of being
visually distinct from real file systems.''
but have never bought this argument and never will. By the same reasoning,
shouldn't FEP filesystem pathnames be visually distinct from their LMFS
counterparts?
The present logical pathname syntax is just too complicated -- it's like
C code (do I have a use a #\; or a #\. here?) -- and more importantly,
makes it unnecessarily hard to express `the root directory' and
`up one directory level' and suchlike.
Another bug with the existing syntax is that it requires at least one level
of directory; this has often annoyed me with lispm logical directories.
One can't say "PCL:>*.*.*", one must instead use "PCL:>PCL>*.*.*" or somesuch.
DEFINE-LOGICAL-PATHNAME-TRANSLATIONS host translations &key [Function]
Define a logical pathname host named <host> (a string or a symbol which
is coerced to a string). <translations> is a list of translations.
Each translation is a list of from-wildcard and to-wildcard.
From-wildcard must be a logical pathname or a string coercible to a
logical pathname. To-wildcard must be a physical pathname or a string
coercible to a physical pathname. Translations are searched in the
order listed, so more specific from-wildcards must precede more general
ones.
3 Because of my point (1) above, I believe that the `left-hand' side of the
translation must be a string which is coerce to a logical pathname by the
[proposed] function (LOGICAL-PATHNAME <host-specified-by-first-arg-to-def-l-p-t> <the-string>)
There are problems with allowing `from-wildcard' to be a logical pathname object:
firstly, it is an error for it to be a logical pathname with a different logical
pathname host and secondly there are conceivable circularity problems with
actually defining or redefining such a form (the pathnames themselves depend
on the result of evaluating the whole form in some sense.)
So I'd require your examples to be written as
;A simple, and typical, example
(define-logical-pathname-translations "FOO"
'((">**>*.*.*" "MY-LISPM:>library>foo>**>")))
;A more complex example
(define-logical-pathname-translations "PROG"
'((">RELEASED>*.*.*" "MY-UNIX:/sys/bin/my-prog/")
(">RELEASED>*>*.*.*" "MY-UNIX:/sys/bin/my-prog/*/")
(">EXPERIMENTAL>*.*.*" "MY-UNIX:/usr/Joe/development/prog/")
(">EXPERIMENTAL>DOCUMENTATION>*.*.*"
"MY-VAX:SYS$DISK:[JOE.DOC]")
(">EXPERIMENTAL>*>*.*.*" "MY-UNIX:/usr/Joe/development/prog/*/")
(">MAIL>**>*.MAIL" "MY-VAX:SYS$DISK:[JOE.MAIL.PROG...]*.MBX")))
with the explicit proviso that the "MY-LISPM:" "MY-UNIX:" etc syntax on the
right-hand sides is implementation-specific
∂26-May-89 0917 CL-Cleanup-mailer Re: issue DYNAMIC-EXTENT-FUNCTION, version 1
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 26 May 89 09:17:16 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 601589; 26 May 89 12:18:51 EDT
Date: Fri, 26 May 89 12:22 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue DYNAMIC-EXTENT-FUNCTION, version 1
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8905261542.AA09977@defun.utah.edu>
Message-ID: <19890526162236.8.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Date: Fri, 26 May 89 09:42:51 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
The last round of discussion on this issue was kind of inconclusive
and then I got distracted with some real work, but I have some time
now to work on a new version. It sounded like there was some support
for the idea of just extending the existing DYNAMIC-EXTENT declaration
to take arguments like (FUNCTION <x>) instead of adding another
declaration just for functions, so that'll probably be in the new
version unless somebody complains.
Okay.
I don't know what to do about the related issue of declaring that an
anonymous lambda has dynamic extent -- none of the alternatives that
have come up so far have much appeal. Anyway, I don't think this
problem is as critical, because you could just restructure the program
to give the function a name.
Do you mean something like:
(defmacro dynamic-extent-lambda (lambda-list &body body)
`(flet ((dummy-name ,lambda-list ,@body))
(declare (dynamic-extent dummy-name))
#'dummy-name))
The problem with this is that the scope of the dynamic-extent declaration
is too small, in fact, so small that this is an erroneous program. That
shows something interesting about the Symbolics sys:downward-function
declaration: the scope that defines the dynamic extent is larger than
the lambda-expression containing the declaration. Implementationally it's
the surrounding function definition, semantically it would be enough for it
to be the surrounding form. I guess you're going to require that
(funcall <foo> (lambda (...) (declare (sys:downward-function)) ...))
be restructured as
(flet ((dummy (...) ...))
(declare (dynamic-extent #'dummy))
(funcall <foo> #'dummy))
which is okay except that it's hard to see how to define a macro that
gives it back a nice non-obtrusive syntax. Maybe
(call-with-dynamic-functions
(funcall <foo> #'(lambda (...) ...)))
Where the call-with-dynamic-functions macro pulls apart its subform
looking for lambda expressions. The macro doesn't need to be in the
standard, programming stylists can define it for themselves. It's
still more obtrusive than something inside the lambda, though.
I think you'd also get the right effect
by declaring that all the closed-over variables and functions
referenced in the lambda have dynamic extent.
I don't think that would mean the same thing. After all, in this example
(let ((a <foo>))
(declare (dynamic-extent a))
(<bar> #'(lambda (z) (if (<baz> z) (<frob> a) (<borf> z)))))
the dynamic extent declaration for A might mean that by the time the
scope of the declaration is exited, something will happen that will
make <baz> return false from then on, so A will no longer be referenced,
even though the closure that was given as an argument to <bar> will
continue to be called. You are correct that the environment of the
closure could be discarded, but I don't see how the closure itself
could be discarded; it would have to have indefinite extent.
So, I don't plan on doing anything about it.
I guess that's probably for the best.
∂26-May-89 0958 CL-Cleanup-mailer Re: Issue: PATHNAME-LOGICAL (version 2)
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 May 89 09:52:18 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA12802@EDDIE.MIT.EDU>; Fri, 26 May 89 12:51:56 EDT
Received: by spt.entity.com (smail2.5); 26 May 89 12:43:48 EDT (Fri)
Date: Fri, 26 May 1989 12:43:48 EDT
From: Gail Zacharias <gz@spt.entity.com>
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@sail.stanford.edu
Subject: Re: Issue: PATHNAME-LOGICAL (version 2)
In-Reply-To: Your message of Wed, 24 May 89 16:40 EDT
Message-Id: <CMM.0.88.612204228.gz@spt.entity.com>
Date: Wed, 24 May 89 16:40 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
I noticed Coral (Macintosh Allegro Common Lisp) has a logical pathname
feature which is somewhat simpler but aimed at solving the same problems.
In particular your feature only affects the directory component and does
not allow wildcard mapping, only one-to-one mapping. Should we say
something about this in the current practice section?
Right, we have logical directory names, to simplify access to sets of files in
differently named directories (an especially severe problem on micros where
everybody just has to have a different pet name for their hard disk). This
isn't really the same as simplifying access to different file systems,
although of course solving the latter automatically solves the former.
We thought about this but
no matter what syntax we choose it's going to be a conflict for
somebody.
Well, it seems like this particular choice conflicts with just about everybody
(except unix), so maybe it's worth considering alternatives...
I could make the alternate argument that the use of colon fits really
nicely into the Macintosh environment, where hd: means the hard disk,
carry: means the floppy disk used for taking stuff between machines, and
pcl: means the logical disk with PCL on it. Does that make sense to
you?
Unfortunately, another very common convention (among the better-organized
types, I guess) is for the floppy used to carry pcl-related stuff between
machines to be called pcl:.
What I'm really concerned about is users finding that loading up pcl "breaks
the file system" because they can no longer open files on their pcl: floppy.
This sort of thing might be less of an issue for lisp machines, where users
tend to live entirely in the lisp machine world and so are more willing to
grant first-class status to lisp-defined conventions. I think on a Mac users
would expect "real" file names to take precedence over any logical names
internal to Lisp.
might be considered
poor in the standard since ! is one of the characters that Common Lisp
has been careful not to use for anything and leave for the users.
But users don't get to do anything with the pathname syntax - they more
or less have to take what the implementation/OS gives them. So this
isn't really taking anything away from users.
But be that as it may, how about '|'? Or '\' (a.k.a. '\\')?
What I think is needed here is a character which is not special in any (or
most) file systems. I.e. it should either be unused (i.e. illegal) or be a
legal (but unusual) filename constituent. The problem with ":" is that it is
a special character in far too many file systems, so it results in an
unresolvable conflict between the logical and physical interpretation. When
the character is a constituent, users can state their intent by either quoting
or not quoting it. Of course "quoting" is implementation dependent, but
that's ok, because the only time you need to quote it is when specifying an
implementation-depend namestring. I'd rather give up a single character
(which can be easily documented) than have this vague situation where what
happens depends entirely on the current set of logical hosts, and there is no
way to specify a physical filename.
The other thing we could do is not standardize logical pathname
namestrings at all, but require some other construct to be used, perhaps
a make-pathname call or a new function (logical-pathname "string"). I
think that would be very ugly and I'd like to avoid it.
Why would it be ugly? Would it still be ugly if there was a reader macro
that called LOGICAL-PATHNAME?
∂26-May-89 1002 CL-Cleanup-mailer Re: issue DYNAMIC-EXTENT-FUNCTION, version 1
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 26 May 89 10:02:37 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA27476; Fri, 26 May 89 11:02:52 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA10054; Fri, 26 May 89 11:02:49 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8905261702.AA10054@defun.utah.edu>
Date: Fri, 26 May 89 11:02:48 MDT
Subject: Re: issue DYNAMIC-EXTENT-FUNCTION, version 1
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Fri, 26 May 89 12:22 EDT
> Date: Fri, 26 May 89 12:22 EDT
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>
> That
> shows something interesting about the Symbolics sys:downward-function
> declaration: the scope that defines the dynamic extent is larger than
> the lambda-expression containing the declaration.
That's the main reason why I'm not really enthusiastic about this
approach -- the scoping rules just don't fit in with the rules for
other declarations.
> I guess you're going to require that
> (funcall <foo> (lambda (...) (declare (sys:downward-function)) ...))
> be restructured as
> (flet ((dummy (...) ...))
> (declare (dynamic-extent #'dummy))
> (funcall <foo> #'dummy))
Yes, this is what I had in mind. Sorry if that wasn't clear in my
original message. I agree that the syntax is rather cumbersome.
> After all, in this example
> (let ((a <foo>))
> (declare (dynamic-extent a))
> (<bar> #'(lambda (z) (if (<baz> z) (<frob> a) (<borf> z)))))
> the dynamic extent declaration for A might mean that by the time the
> scope of the declaration is exited, something will happen that will
> make <baz> return false from then on, so A will no longer be referenced,
> even though the closure that was given as an argument to <bar> will
> continue to be called.
I guess we differ over what "referenced" means. My interpretation is
that the closure references A regardless of whether or not the piece
of code which references A inside the closure is actually executed on
any particular invocation, and that it's therefore an error to say
that A has dynamic extent unless the closure also has dynamic extent.
Maybe the real problem is that the DYNAMIC-EXTENT proposal didn't
formally define what "inaccessible" means. I'm relying on an
intuitive idea of what parts of a closure a garbage collector would
have to scan.
-Sandra
-------
∂25-May-89 1249 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (version 4), PATHNAME-COMPONENT-VALUE (version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 25 May 89 12:48:57 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 600738; 25 May 89 12:04:22 EDT
Date: Thu, 25 May 89 12:08 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (version 4), PATHNAME-COMPONENT-VALUE (version 2)
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <890524-233428-10964@Xerox>
Message-ID: <19890525160824.7.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Date: 24 May 89 23:34 PDT
From: masinter.pa@Xerox.COM
I think it is intolerable that different implementations talk about the
*same* file system in different ways.
I agree. I think PATHNAME-COMPONENT-VALUE is actually the right issue
in which to discuss that, although there is certainly much interaction
with other pathname issues, but if we proceed assuming that they pass,
we should be able to prescribe exact pathname component values for at
least the key file systems MS/DOS, Macintosh, Unix, and VAX/VMS. I would
be more than willing to add to the proposal specific prescriptions for the
pathname component values in particular operating systems, except that
I cannot write this by myself. If some other members of the cleanup
committee will volunteer to help for particular systems, I will mail out
next week a draft writeup, or at least a framework, which they can then
correct. How does that sound?
∂27-May-89 1552 CL-Cleanup-mailer PARSE-BODY
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 27 May 89 15:52:15 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA05167g; Sat, 27 May 89 15:51:12 PDT
Received: by bhopal id AA19002g; Sat, 27 May 89 15:50:44 PDT
Date: Sat, 27 May 89 15:50:44 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8905272250.AA19002@bhopal>
To: cl-cleanup@sail.stanford.edu
Subject: PARSE-BODY
Guy Steele's "Clarifications" of 6-Dec-85 proposed adding a function
PARSE-BODY. After passage of the proposal that cancelled the use of
macroexpansions for declarations, interest in this function died out,
with the excuse given that it could now be written portably (since it
no longer had to deal with macroexpanding any body forms).
However, this excuse appears to be short-sighted, since the main
purpose of a standard is not kernelization, but to ensure a standard
way of doing things. Way back when, Lucid implemented PARSE-BODY exactly
according to Steele's description; but apparently not enough other
implementations did so. Consequently, PCL carries its own idiosyncratic
version called EXTRACT-DECLARATIONS. Below is a copy of a note sent
to the PCL mailing list musing about the matter. Despite the sender's
confusion on a minor matter, it does illustrate the value of agreeing
to a standard interface, regardless of how easy it might be to code it.
-- JonL --
Return-Path: <duff@unclejack.crd.ge.com>
Redistributed: commonloops.PA
Date: Thu, 25 May 89 13:57:34 EDT
From: duff@unclejack.crd.ge.com (David A Duff)
To: commonloops.PA@Xerox.COM
Subject: minor point about extract-declarations
Reply-To: duff@eraserhead.crd.ge.com
hello.
the macro EXTRACT-DECLARATIONS, defined in macros.lisp performs a function
that is very useful to me. looking at it more closely, however, revealed
either a discrepancy in the code or in my understanding of Steele's
description of common lisp.
the macro only returns at most one docstring and it assumes that the
docstring, if present will always be the first thing in the body. Steele
seems to indicate that multiple docstrings are allowable and that they can be
interspersed with the declarations.
has there been some sort of cleanup or clarification of Steele on this issue?
i personally, can't see much point in allowing docstrings to be interspersed
with declarations, and i don't know what the correct way would be to handle
more than one (i don't think Steele says anything about this).
Dave Duff GE Corporate Research and Development
duff@eraserhead.crd.ge.com Schenectady, NY 12309
∂29-May-89 1311 CL-Cleanup-mailer Re: Issue: PATHNAME-SYSTEM-TYPE (version 1)
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 29 May 89 13:11:01 PDT
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP
id aa10070; 29 May 89 20:55 BST
Date: Mon, 29 May 89 21:00:15 BST
Message-Id: <11096.8905292000@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: Re: Issue: PATHNAME-SYSTEM-TYPE (version 1)
To: sandra (Sandra J Loosemore) <@cs.utah.edu:sandra@defun>,
"David A. Moon" <Moon@stony-brook.scrc.symbolics.com>
Cc: CL-Cleanup@sail.stanford.edu, gray%dsg.csc.ti.com@NSFnet-Relay.AC.UK
> > Date: Thu, 25 May 89 16:55 EDT
> > From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> >
> > Since you're the one who says that pathname manipulating programs are
> > best written by getting namestrings and doing string processing on
> > them, can you tell me how your programs know what syntax to expect
> > in the namestrings?
>
> I've never said anything like that and I think it's a crummy idea
> anyway. What I *have* said is that the only pathname operations that
> a portable program can expect to do that make sense on all file
> systems are:
The only use Sandra gives for _pathnames_ (as opposed to strings)
that's at all interesting is the ability to merge pathnames. But,
of course, that too could be done with strings.
I have had a lot of difficulty understanding how pathnames are
supposed to be used in portable ways. When I've thought I've
understood an issue, I often find my explanation is almost the
opposite of one later given by, say, KMP. Nonetheless, I am
sure there are useful things that can be done with pathnames,
if only because the Symbolics folk (who are not idiots) keep
saying so.
But even if there are no completely portable uses of pathnames,
I absolutely reject the argument that anything that is not
completely portable should be eliminated from the language.
I am also unhappy with the suggestion that pathnames might
be allowed to exist nut without any MAKE-PATHNAME that constructs
them.
∂30-May-89 0544 CL-Cleanup-mailer PARSE-BODY
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 30 May 89 05:44:36 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 602551; 30 May 89 08:44:59 EDT
Date: Tue, 30 May 89 08:44 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: PARSE-BODY
To: jonl@lucid.com
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8905272250.AA19002@bhopal>
Message-ID: <19890530124448.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Sat, 27 May 89 15:50:44 PDT
From: Jon L White <jonl@lucid.com>
... Lucid implemented PARSE-BODY exactly according to Steele's description;
but apparently not enough other implementations did so. ...
I don't recall Steele's description. Cloe implements a function named PARSE-BODY
internally which may or may not be related:
(PARSE-BODY body env) => forms, decls, docs
All three return values are lists (for convenience with ",@"), but the `docs'
value never contains more than one string.
There is a discrepancy between the formal syntax description of DEFUN and
LAMBDA on p67 and the text that follows two paragraphs below. The paragraph
which begins with "If the optional..." ends with "It is an errro if more than
one doc-string is present." I have always (since I noticed it, anyway :-)
taken the text to have priority over the syntax description. My guess is that
Mr. Duff didn't notice the text override.
Cloe's PARSE-BODY (used in implementing New Flavors, for example) signals the
error, though not for any highly principled reason.
Btw, the correct way for Steele to have written the syntax to avoid this
confusion would presumably have been:
lambda lambda-list {declaration}* [doc-string] {declaration}* {form}*
-- though it looks fairly yucky. Probably better would have been to strike
the one-doc-string restriction and just permit multiple doc strings. That
way, people could write:
(defun foo ()
"This is a very long doc string"
"that didn't fit all one one line."
...)
I certainly believe that would be more aesthetic than:
(defun foo ()
"This is a very long doc string
that didn't fit all one one line"
...)
or:
(defun foo ()
"This is a very long doc string
that didn't fit all one one line"
...)
As I recall, this was discussed explicitly in the production of CLtL. The
main issue was what DOCUMENTATION would produce in the case of multiple
doc strings. My preference was then (and is now) to have DOCUMENTATION do
(FORMAT NIL "~{~A~↑~%~}" strings)
in order to support multiple doc strings as a solution to the `indentation
problem' cited above.
Summary:
- I'm fairly agnostic about whether PARSE-BODY should be there. It's less
needed now that there is no macro expansion to contend with, but the idiom
of extracting DECLARE expressions from the top of a body is still needed
even so, and this does help to do that concisely, so my personal inclination
toward the feature would probably be mildly positive.
- I don't think there is an ambiguity about doc strings, but I do think the
restriction is gratuitous and would not oppose its removal. This would
simplify the syntax description and admit a programming style that some
would find useful. Clarifications of how DOCUMENTATION and PARSE-BODY
treated the situation would be in order.
∂30-May-89 0907 CL-Cleanup-mailer Re: Issue: PATHNAME-LOGICAL (version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 30 May 89 09:07:16 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 30 MAY 89 09:07:36 PDT
Date: 30 May 89 09:07 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-LOGICAL (version 2)
In-reply-to: Gail Zacharias <gz@spt.entity.com>'s message of Fri, 26 May 89
12:43:48 EDT
To: CL-Cleanup@sail.stanford.edu
Message-ID: <890530-090736-7241@Xerox>
I think this discussion is leading in a productive direction. Standardizing
on a funny syntax for namestrings on the grounds that it is "different
enough" from the file systems we know about seems like we're going in the
wrong direction; it presumes that we know about all possible file systems
to which the Standard might need to be connected.
If we want to do anything about logical pathnames at all, building Lisp
constructors for them (either as a new function, MAKE-LOGICAL-PATHNAME, or
possibly a just new keyword for MAKE-PATHNAME which can be used instead of
host+device+directory) sounds less likely to lead us into trouble.
∂04-Jun-89 1215 CL-Cleanup-mailer Re: minor point about extract-declarations
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Jun 89 12:15:03 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 04 JUN 89 12:13:36 PDT
Date: Sun, 4 Jun 89 12:13 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: minor point about extract-declarations
To: duff@eraserhead.crd.ge.com, Jon L White <jonl@lucid.com>, Kent M Pitman
<KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: cl-cleanup@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-6.text.newest
In-Reply-To: <8905251757.AA06245@unclejack.crd.Ge.Com>,
<8905272250.AA19002@bhopal>,
<19890530124448.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890604191319.8.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no
Date: Thu, 25 May 89 13:57:34 EDT
From: duff@unclejack.crd.ge.com (David A Duff)
the macro EXTRACT-DECLARATIONS, defined in macros.lisp performs a function
that is very useful to me. looking at it more closely, however, revealed
either a discrepancy in the code or in my understanding of Steele's
description of common lisp.
Date: Sat, 27 May 89 15:50:44 PDT
From: Jon L White <jonl@lucid.com>
Guy Steele's "Clarifications" of 6-Dec-85 proposed adding a function
PARSE-BODY. After passage of the proposal that cancelled the use of
macroexpansions for declarations, interest in this function died out,
with the excuse given that it could now be written portably (since it
no longer had to deal with macroexpanding any body forms).
However, this excuse appears to be short-sighted, since the main
purpose of a standard is not kernelization, but to ensure a standard
way of doing things.
Date: Tue, 30 May 89 08:44 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- I'm fairly agnostic about whether PARSE-BODY should be there. It's less
needed now that there is no macro expansion to contend with, but the idiom
of extracting DECLARE expressions from the top of a body is still needed
even so, and this does help to do that concisely, so my personal inclination
toward the feature would probably be mildly positive.
- I don't think there is an ambiguity about doc strings, but I do think the
restriction is gratuitous and would not oppose its removal. This would
simplify the syntax description and admit a programming style that some
would find useful. Clarifications of how DOCUMENTATION and PARSE-BODY
treated the situation would be in order.
I would be content to see PARSE-BODY defined either way. I prefer
Kent's proposal because I always hate documentation strings like:
(defun foo ()
"This is a very long doc string
that didn't fit all one one line"
...)
Of course I would far more gladly cast my vote for the elimination of
documentation strings, but I doubt that would pass. In the absence of
such an event, I would like to see PARSE-BODY added to the language.
For David Duff, as soon as CL-CLEANUP comes up with a proposal or at
least a decision about multiple documentation strings, I will implement
and support it in PCL.
-------
∂05-Jun-89 1447 CL-Cleanup-mailer minor point about extract-declarations
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 5 Jun 89 14:47:36 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA16793g; Mon, 5 Jun 89 14:44:30 PDT
Received: by bhopal id AA00890g; Mon, 5 Jun 89 14:46:43 PDT
Date: Mon, 5 Jun 89 14:46:43 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8906052146.AA00890@bhopal>
To: Gregor.pa@Xerox.COM
Cc: duff@eraserhead.crd.ge.com, KMP@STONY-BROOK.SCRC.Symbolics.COM,
cl-cleanup@sail.stanford.edu
In-Reply-To: Gregor.pa@Xerox.COM's message of Sun, 4 Jun 89 12:13 PDT <19890604191319.8.GREGOR@SPIFF.parc.xerox.com>
Subject: minor point about extract-declarations
Could we actually support a new cleanup issue based on the fact that
Guy Steele's "Clarifications" has already been around for n years? If
so, the minimal thing would be to support it just as Steele had it.
I really don't see why CLtL p67 is inconsistent about the multiplicities
of doc-string and declaration; but it's probably too late to change that
now.
-- JonL --
∂08-Jun-89 1721 CL-Cleanup-mailer Re: Issue: PATHNAME-WILD (version 5)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 8 Jun 89 17:21:00 PDT
Received: by ti.com id AA05063; Thu, 8 Jun 89 18:41:14 CDT
Received: from Kelvin by tilde id AA26425; Tue, 6 Jun 89 19:27:09 CDT
Message-Id: <2822171220-15473020@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 6 Jun 89 19:27:00 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@sail.stanford.edu
Subject: Re: Issue: PATHNAME-WILD (version 5)
In-Reply-To: Msg of Tue, 23 May 89 13:24 EDT from David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> Proposal (PATHNAME-WILD:NEW-FUNCTIONS):
>
> Introduce the following three functions:
>
> WILD-PATHNAME-P pathname &optional field-key
...
> If a non-null <field-key> is provided, it must be one of :HOST, :DEVICE,
> :DIRECTORY, :NAME, :TYPE, or :VERSION.
I was worried that permitting (WILD-PATHNAME-P <path> :HOST) implied
that the host component might be wild, which is impossible in our
implementation. But I see that proposal
PATHNAME-COMPONENT-VALUE:SPECIFY clarifies that the standard does not
require support for wild hosts. So you might want to mention here that
(WILD-PATHNAME-P <path> :HOST) is allowed just in case some
implementation might support wild hosts as an extension.
> Current Practice:
>
> Presumably no implementation supports the proposal exactly as stated.
> Symbolics Genera has had similar features under different names for many
> years:
>
> (SEND pathname :WILD-P) returns a value such as NIL, :NAME, :TYPE,
> etc., indicating the first wild field.
>
> (SEND pathname :NAME-WILD-P), (SEND pathname :DIRECTORY-WILD-P),
> etc. test individual fields.
>
> The :TRANSLATE-WILD-PATHNAME, :TRANSLATE-WILD-PATHNAME-REVERSIBLE, and
> :PATHNAME-MATCH messages resemble TRANSLATE-PATHNAME and
> PATHNAME-MATCH-P.
The Explorer also supports the messages :WILD-P (although it only
returns NIL or T), :NAME-WILD-P, etc., :TRANSLATE-WILD-PATHNAME, and
:PATHNAME-MATCH.
> The clarification is current practice as far as the authors are aware.
> If some implementations are found that specify a meaning for wildcard
> pathnames as arguments to these functions, this proposal should be changed
> to say that the consequences are unspecified rather than signalling an error.
The Explorer permits DELETE-FILE on a wild pathname, meaning to delete
all files that match.
∂08-Jun-89 1723 CL-Cleanup-mailer Re: Issue: PATHNAME-LOGICAL (version 2)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 8 Jun 89 17:23:07 PDT
Received: by ti.com id AA05043; Thu, 8 Jun 89 18:40:46 CDT
Received: from Kelvin by tilde id AA25501; Tue, 6 Jun 89 18:08:51 CDT
Message-Id: <2822166522-15190737@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 6 Jun 89 18:08:42 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@sail.stanford.edu
Subject: Re: Issue: PATHNAME-LOGICAL (version 2)
In-Reply-To: Msg of Tue, 23 May 89 13:21 EDT from David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> Proposal (PATHNAME-LOGICAL:ADD):
Basically I like this proposal. We use logical pathnames a lot, and
this proposal would make them even better without appearing to require
any incompatible change for us.
> The syntax of a logical pathname namestring is as follows:
>
> host ":" { directory ";" }* [ name ] [ "." type [ "." version ]]
I would prefer to use "#" as the version prefix. More than once I've
been annoyed when using Symbolics pathnames to not be able to specify a
version without also specifying the type.
> A word consists of one to twelve uppercase letters, digits, and hyphens.
> Lowercase letters are translated to uppercase. The consequences of using
> other characters, or more than twelve characters, are unspecified.
The 12-character limit doesn't seem to have any clear significance.
Since it is common for older file systems to have an 8-character limit
for file names, maybe it would be more meaningful to say that names can
be any length, but only the first 8 characters are guaranteed to be
significant on all implementations.
> There is no device, so the device component of a logical pathname is
> always :UNSPECIFIC. No other component can be :UNSPECIFIC.
I presume you mean that the standard doesn't specify any portable
meaning for an :UNSPECIFIC component, and don't intend to rule out its
use in generic pathnames as an extension?
> DEFINE-LOGICAL-PATHNAME-TRANSLATIONS host translations &key [Function]
>
> Define a logical pathname host named <host> (a string or a symbol which
> is coerced to a string). <translations> is a list of translations.
> Each translation is a list of from-wildcard and to-wildcard.
> From-wildcard must be a logical pathname or a string coercible to a
> logical pathname.
Could we say
... coercible to a logical pathname using "<host>:" as the
default pathname.
so that the host doesn't have to be explicitly supplied every time?
> ... To-wildcard must be a physical pathname or a
> coercible to a physical pathname.
Is there any reason to not permit this to be another logical pathname?
> There are no keyword arguments specified by this standard, but any
> implementation extensions are provided as keyword arguments or as
> translations with more than two elements.
An extension I would like to have is the ability to specify what syntax
will be used for parsing the name strings. If I'm using logical
pathnames for my own convenience, rather than portability, then I would
like to be able to use whatever pathname syntax I like the most.
> Current practice:
The Explorer also has a comparable logical pathname facility, although
the translation mechanism is unfortunately less general than proposed
here. The namestring syntax used is slightly different:
host ":" [{directory "."}* directory ";"] [name] ["." type] ["#" version]
The newest version is indicated by ">" instead of "newest".
∂08-Jun-89 1723 CL-Cleanup-mailer Re: Issue: PATHNAME-LOGICAL (version 2)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 8 Jun 89 17:23:45 PDT
Received: by ti.com id AA05020; Thu, 8 Jun 89 18:40:14 CDT
Received: from Kelvin by tilde id AA24737; Tue, 6 Jun 89 17:15:26 CDT
Message-Id: <2822163312-14997875@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 6 Jun 89 17:15:12 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Gail Zacharias <gz@spt.entity.com>
Cc: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>,
CL-Cleanup@sail.stanford.edu
Subject: Re: Issue: PATHNAME-LOGICAL (version 2)
In-Reply-To: Msg of Fri, 26 May 1989 12:43:48 EDT from Gail Zacharias <gz@spt.entity.com>
> We thought about this but
> no matter what syntax we choose it's going to be a conflict for
> somebody.
>
> Well, it seems like this particular choice conflicts with just about everybody
> (except unix), so maybe it's worth considering alternatives...
On the Explorer, we use the colon as the host delimiter for all
pathnames, which includes support for files on Symbolics, VAX-VMS,
MS-DOS, Multics, and Macintosh as well as Unix, the local Explorer
files, and logical pathnames. This has not been seen to be a problem.
True, for MS-DOS and Macintosh pathnames, a host must always be supplied
since the first colon is taken to be a host delimiter. Even this hasn't
been considered to be a problem, but that is probably just because we
are in the habit of always specifying the host anyway because the
pathname defaulting facilities in our environment are too unpredictable
to be of much use.
I can see, though, that if you are on a non-networked Macintosh, it
could be annoying to have to specify the host even though there is only
one host that you are using.
I wonder, since neither MS-DOS or Macintosh pathnames use the semicolon
[the proposed logical pathname directory delimiter], if it would be
reasonable in such an environment to consider the first colon to be a
host delimiter only if the namestring contains a semicolon? Since it
would be unusual to want to use a namestring consisting of only a host
name, that could be a useful way of avoiding the ambiguity.
∂11-Jun-89 1226 CL-Cleanup-mailer issue DYNAMIC-EXTENT-FUNCTION, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 11 Jun 89 12:26:05 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA04581; Sun, 11 Jun 89 13:26:28 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA20929; Sun, 11 Jun 89 13:26:25 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906111926.AA20929@defun.utah.edu>
Date: Sun, 11 Jun 89 13:26:24 MDT
Subject: issue DYNAMIC-EXTENT-FUNCTION, version 2
To: cl-cleanup@sail.stanford.edu
I apologize for taking so long to finish this up -- I keep getting
distracted with "real work" lately....
Forum: CLEANUP
Issue: DYNAMIC-EXTENT-FUNCTION
References: Scope and Extent
Issue DYNAMIC-EXTENT
Category: ADDITION
Edit history: 04-Apr-89, Version 1 by Loosemore
11-Jun-89, Version 2 by Loosemore
Problem Description:
Proposal DYNAMIC-EXTENT:NEW-DECLARATION, passed at the March 89
meeting, provides a mechanism for declaring that the values of
variables have only dynamic (rather than indefinite) extent. It
would be useful to have similar functionality to indicate that
functional bindings may have only dynamic extent. (For example,
this would permit compilers to stack-allocate closures.)
Proposal (DYNAMIC-EXTENT-FUNCTION:EXTEND):
Extend the DYNAMIC-EXTENT declaration to accept arguments that are
lists of the form (FUNCTION <name>) where <name> is a function name,
as well as symbols.
A (FUNCTION <name>) list appearing in a DYNAMIC-EXTENT declaration is
used to declare that the lexically visible functional binding of <name>
has dynamic extent. Except for the interpretation of <name> as the
name of a function instead of the name of a variable, such a declaration
otherwise has semantics that are identical to those already described
in proposal DYNAMIC-EXTENT:NEW-DECLARATION.
Rationale:
This permits a programmer to offer advice to an implementation about
what functions may be stack-allocated for efficiency.
It may be difficult or impossible for a compiler to infer this
same information statically.
Current Practice:
JonL says that Lucid's compiler can stack-allocate closures, but they
have no mechanism for programmers to give the compiler permission to
do so.
HPCL-I has an UPWARD-CLOSURES declaration that pervasively affects
all closures created within the scope of the declaration.
The Symbolics Genera compiler can often infer when functions can be
implemented to have dynamic extent. Also, if a function has a
SYS:DOWNWARD-FUNCTION declaration in front of its body, then the
function is implemented with dynamic extent regardless of whether
the compiler thinks all uses are "downward". (This declaration is
rather peculiar because its scope is actually larger than the lambda
expression containing the declaration; implementationally, it's the
surrounding function definition.)
Cost to Implementors:
No cost is forced since implementations are permitted to simply
ignore the DYNAMIC-EXTENT declaration.
Cost to Users:
None. This change is upward compatible.
There may be some hidden costs to debugging using this declaration (or any
feature which permits the user to access dynamic extent objects without
the compiler proving that they are appropriate). If the user misdeclares
something and returns a pointer into the stack (or stores it in the heap),
an undefined situation may result and the integrity of the Lisp storage
mechanism may be compromised. Debugging these situations may be tricky,
but users who have asked for this feature have indicated a willingness
to deal with such costs. Nevertheless, the perils should be clearly
documented and casual users should not be encouraged to use this
declaration.
Cost of Non-Adoption:
Some portable code would be forced to run more slowly (due to
GC overhead), or to use non-portable language features.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
This declaration allows a fairly low level optimization to work
by asking the user to provide only very high level information.
The alternatives (sharpsign conditionals, some of which may
lead to more bit-picky abstractions) are far less aesthetic.
Discussion:
Loosemore supports DYNAMIC-EXTENT-FUNCTION:EXTEND.
This proposal does not attempt to address the issue of specifying
dynamic extent for anonymous closures (which is really a special case
of the more general problem of specifying dynamic extent for unnamed
objects of any type). It's possible, although often awkward, to
restructure the program to give the object a name and explicitly
identify its extent.
One possible solution to the problem of dynamic extent for anonymous
lambdas would be to clarify that a reference to a closed-over variable
or function appearing lexically within a FUNCTION form is enough to
cause its value to be "saved" when the FUNCTION form is executed,
regardless of whether or not that reference is actually executed when
the resulting function is called. Then, if all of the closed-over
functions and variables referenced within a closure are declared to
have dynamic extent, the closure could be assumed to have dynamic
extent as well. (More precisely, its maximum extent would be the
intersection of the extents of the closed-over functions and
variables.)
-------
∂12-Jun-89 1130 CL-Cleanup-mailer issue DYNAMIC-EXTENT-FUNCTION, version 2
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 12 Jun 89 11:30:29 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA20149g; Mon, 12 Jun 89 11:28:17 PDT
Received: by bhopal id AA10549g; Mon, 12 Jun 89 11:30:28 PDT
Date: Mon, 12 Jun 89 11:30:28 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8906121830.AA10549@bhopal>
To: sandra%defun@cs.utah.edu
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Sun, 11 Jun 89 13:26:24 MDT <8906111926.AA20929@defun.utah.edu>
Subject: issue DYNAMIC-EXTENT-FUNCTION, version 2
re: . . . Except for the interpretation of <name> as the
name of a function instead of the name of a variable, such a declaration
otherwise has semantics that are identical to those already described
in proposal DYNAMIC-EXTENT:NEW-DECLARATION.
I like this. It really says what I think is preferable -- that the
declaration DYNAMIC-EXTENT applies to name-bindings, whether "value"
or "functional". Had we had a bit more foresight, this might have
gotten into the original proposal, but it's no big deal to have two
proposals.
-- JonL --
∂12-Jun-89 1522 CL-Cleanup-mailer Re: Issue: PATHNAME-WILD (version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 12 Jun 89 15:21:56 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 609988; 12 Jun 89 18:23:43 EDT
Date: Mon, 12 Jun 89 18:24 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-WILD (version 5)
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>, David N Gray <Gray@DSG.csc.ti.com>
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <8905252006.AA09216@defun.utah.edu>,
<2822171220-15473020@Kelvin>
Message-ID: <19890612222403.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
I'm having trouble finding the time to write up revised versions
of these issues, based on your comments, but here is an acknowledgement
of your comments and some responses.
Date: Thu, 25 May 89 14:06:18 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
I don't understand what all the arguments to TRANSLATE-PATHNAME are
for. I guess that this function is intended to be a merging operation
that fills in wildcard components in one pathname with matching
components from another pathname, but I don't understand why you need
to pass in two wildcard pathnames instead of one,
It's not a merging operation, it's a translating operation. The two wildcard
pathnames tell you what translates to what. I suppose that's not any clearer
than what the issue writeup said; I'll try to improve the way this is
described, if I can find the time. I take it the example that was given
in the writeup didn't help? Could you constructively criticize it?
or what reversibility really implies.
Reversibility is easy, it means it obeys the invariant given in the
proposal. The hard question is what does irreversibility really imply
(i.e. why don't we just make it reversible all the time?) and that's hard
because it's implementation-dependent. The basic idea is that Common Lisp
can't dictate any particular wildcard matching and translating algorithm,
because every file system has its own idea of what's right, and we'd get
into a religious war if we tried to dictate some particular algorithm.
I got kind of lost reading the
description of this function -- isn't there a more concise way to
state what is going on?
I'll look for one. Thanks for the feedback.
Date: Tue, 6 Jun 89 19:27:00 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
I was worried that permitting (WILD-PATHNAME-P <path> :HOST) implied
that the host component might be wild, which is impossible in our
implementation. But I see that proposal
PATHNAME-COMPONENT-VALUE:SPECIFY clarifies that the standard does not
require support for wild hosts. So you might want to mention here that
(WILD-PATHNAME-P <path> :HOST) is allowed just in case some
implementation might support wild hosts as an extension.
I'm not sure how much of PATHNAME-COMPONENT-VALUE to copy into
PATHNAME-WILD; my preference is to copy as little as possible, to
minimize the chance for creating inconsistencies. Perhaps the rationale
section should just say that WILD-PATHNAME-P might always return NIL in
some implementations or something.
> Current Practice:
The Explorer also supports the messages :WILD-P (although it only
returns NIL or T), :NAME-WILD-P, etc., :TRANSLATE-WILD-PATHNAME, and
:PATHNAME-MATCH.
Will add.
> The clarification is current practice as far as the authors are aware.
> If some implementations are found that specify a meaning for wildcard
> pathnames as arguments to these functions, this proposal should be changed
> to say that the consequences are unspecified rather than signalling an error.
The Explorer permits DELETE-FILE on a wild pathname, meaning to delete
all files that match.
I don't think this should be a mandated feature, but we can add it to current
practice. Do you think this feature of the Explorer is good or a wart? I.e.
would you like the proposal to say that the consequences are unspecified, or
would you like the proposal to require the Explorer to change?
∂12-Jun-89 1601 CL-Cleanup-mailer Issue: PATHNAME-LOGICAL (version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 12 Jun 89 16:01:23 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 610027; 12 Jun 89 19:02:25 EDT
Date: Mon, 12 Jun 89 19:02 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-LOGICAL (version 2)
To: Richard Mlynarik <Mly@AI.AI.MIT.EDU>, Sandra J Loosemore <sandra%defun@cs.utah.edu>,
Gail Zacharias <gz@spt.entity.com>, masinter.pa@Xerox.COM, David N Gray <Gray@DSG.csc.ti.com>
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <19890526160304.1.MLY@ANNA-MAGDALENA-BACH.AI.MIT.EDU>,
<8905251939.AA09185@defun.utah.edu>,
<CMM.0.88.612204228.gz@spt.entity.com>,
<890530-090736-7241@Xerox>,
<2822163312-14997875@Kelvin>,
<2822166522-15190737@Kelvin>
Message-ID: <19890612230247.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
I'm having trouble finding the time to write up revised versions of
these issues, based on your comments, but here is an acknowledgement of
your comments (including the ones not copied in this reply!) and some
responses to some of the comments.
Date: Thu, 25 May 89 12:38 EDT
From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
1 I believe that mixing in the issue of parsing out host components from
pathname namestrings is a real mistake....
To my thinking, a much better idea would be to define a new function, say,
(LOGICAL-PATHNAME <host-name> <namestring>) which would return a logical
pathname.
See comments below after GZ's message. I don't think I can write up a
revised version of the proposal until this is resolved, so far I'm still
mulling it over in my own mind and don't have a firm opinion yet.
2 My second problem is with the syntax of the pathnames.
I'll mull over these comments too, although I'd like to point out that
I don't think logical pathnames should be asked to represent all features
of all (or even most) real file systems.
Date: Thu, 25 May 89 13:39:52 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
I don't understand why there's any need for magic numbers (12 and 6)
and restrictions on what characters may appear in a logical pathname
component. The rationale says this is an arbitrary decision, but
doesn't address the question of why restrictions are necessary at all.
I think these length limits were a mistake, and I propose to remove them
in version 3 of the proposal. It is always up to the person who writes
the translation rules for a particular logical pathname host to a
particular physical file system to make sure that the pathnames that are
going to be used translate to valid pathnames for the particular file
system. The length limits were supposed to make that easier to do, but
they didn't. I'll put in an example showing how to do this for your
favorite (!) file system, the Cray with 6 character names and no
directories, types, or versions.
The proposal mentions that not all filesystems support versions and
that versions in logical pathnames can't be used portably. More
generally, not all filesystems have notions of hosts, devices,
directories, and file types either. (In other words, about the only
thing you can depend on a filename always having is a name.) Why treat
versions as a special case, but ignore all the other problems?
Because the other fields can be addressed by translation, but it doesn't
really make sense to do that for versions. Actually, this is not an
absolute, versions could be done by translation. However, the typical
use of versions is such that on a file system without versions, people
would rather just store one version, and not specify translations that
will preserve the version information by encoding it in the name. This
is different from the typical use of types or directories, where the
files with different values in those components are truly distinct and
everything would break if you only kept one of them.
At least, that's what I thought. Perhaps I was wrong and we would
rather mandate that versions always work in logical pathnames,
translating into whatever is necessary to preserve the information.
Another possibility that might bear thinking about is to say that
logical pathnames never have versions, but I know that some development
systems make very effective use of file version numbers, so I'm reluctant
to just rule them out entirely.
How are functions like OPEN supposed to map a logical pathname onto a real
pathname? (Does it do it in the same way as TRANSLATE-LOGICAL-PATHNAME or
can it use some other mapping?)
They don't have to actually call the function TRANSLATE-LOGICAL-PATHNAME, but
they have to produce the same result. This should have been explicit in the
proposal.
The dependence on issue PATHNAME-WILD (the functions PATHNAME-MATCH-P
and TRANSLATE-PATHNAME that are referenced in the description of
TRANSLATE-LOGICAL-PATHNAME) ought to be made more explicit. What
happens if PATHNAME-WILD fails?
I thought it said somewhere that PATHNAME-LOGICAL cannot pass if
PATHNAME-WILD fails.
LOAD-LOGICAL-PATHNAME-TRANSLATIONS sounds suspiciously like REQUIRE --
I'm sure that's a bad sign...
It does, but I hope that being much more task-specific, it doesn't really
have the same problems.
COMPILE-FILE-PATHNAME doesn't seem to have anything to do with the
rest of this proposal.
It's another part of what you need to actually use logical pathnames for
storing programs. Suppose you want to call COMPILE-FILE only if the source
file is newer than the compiled file. To do that, you have to have a way
to know the name of the compiled file without actually calling COMPILE-FILE.
I could have proposed that logical pathnames always use a specific naming
convention for compiled files, as I did for source files, but for compiled
files it seemed better to let the implementation control the name. Do
you think a different approach should have been taken, or did you just
want to see this proposal split into parts?
In general, I don't really see what this proposal buys the user that
can't already be achieved using other mechanisms that are already part
of the language. For example, when I have some files that live in
different places on different hosts, I usually put a pathname
containing the appropriate pathname for that place in a variable and
call MERGE-PATHNAMES to get the full pathnames of the individual
files. Logical pathnames don't eliminate the necessity of having
literal, host-specific pathnames in a program; you still have to
supply them to DEFINE-LOGICAL-PATHNAME-TRANSLATIONS.
Then you've missed the point, which should have been described more
clearly in the issue writeup.
The call to DEFINE-LOGICAL-PATHNAME-TRANSLATIONS isn't part of the
program, it's separate. That separation, and a uniform convention
for how to do the separation, are the key aspects of logical pathnames.
I agree that Common Lisp is Turing-machine-equivalent with or without
logical pathnames, or, more seriously, that each user could implement
something like logical pathnames for himself. The reason to standardize
it is so everyone will do it the same and so individual users can spend
their time writing applications instead of doing this kind of system
programming. Note that your way sounds simple, but it doesn't stay
simple when you get into more complicated situations such as program
generated file names or porting a program developed on a system with
long file names onto a system with a very restrictive limit on the
length of file names.
Date: Fri, 26 May 1989 12:43:48 EDT
From: Gail Zacharias <gz@spt.entity.com>
.... [discussion of various logical namestring syntax ideas]
I don't know what I think yet about whether logical pathnames should
have a namestring syntax that is specified to be distinguishable from
all physical pathname namestrings, or whether there should be a
LOGICAL-PATHNAME function distinct from the PATHNAME function. I'm
suspicious of the latter idea because I know that in current practice it
is very common to have strings that are sometimes one kind of pathname
and sometimes the other kind; thus it seems desirable to have all the
operations, including parsing, be generic for both kinds of pathnames.
What if you have a string that is just "FOO", i.e. just a name
component? However, I haven't had time to think out the full
implications of this issue yet. The suggestion to have two distinct
spaces of namestrings was not something I had anticipated and the
implications require substantial thought. Current practice in Symbolics,
Explorer, and Coral has one namespace for both logical and physical
namestrings.
Date: 30 May 89 09:07 PDT
From: masinter.pa@Xerox.COM
I think this discussion is leading in a productive direction. Standardizing
on a funny syntax for namestrings on the grounds that it is "different
enough" from the file systems we know about seems like we're going in the
wrong direction; it presumes that we know about all possible file systems
to which the Standard might need to be connected.
If we want to do anything about logical pathnames at all, building Lisp
constructors for them (either as a new function, MAKE-LOGICAL-PATHNAME, or
possibly a just new keyword for MAKE-PATHNAME which can be used instead of
host+device+directory) sounds less likely to lead us into trouble.
Maybe, or maybe more likely to lead us into trouble; see above. I'm still
thinking this one over.
Date: Tue, 6 Jun 89 17:15:12 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
> Well, it seems like this particular choice conflicts with just about everybody
> (except unix), so maybe it's worth considering alternatives...
On the Explorer, we use the colon as the host delimiter for all
pathnames, which includes support for files on Symbolics, VAX-VMS,
MS-DOS, Multics, and Macintosh as well as Unix, the local Explorer
files, and logical pathnames. This has not been seen to be a problem.
Same in Genera.
True, for MS-DOS and Macintosh pathnames, a host must always be supplied
since the first colon is taken to be a host delimiter. Even this hasn't
been considered to be a problem, but that is probably just because we
are in the habit of always specifying the host anyway because the
pathname defaulting facilities in our environment are too unpredictable
to be of much use.
I can see, though, that if you are on a non-networked Macintosh, it
could be annoying to have to specify the host even though there is only
one host that you are using.
I wonder, since neither MS-DOS or Macintosh pathnames use the semicolon
[the proposed logical pathname directory delimiter], if it would be
reasonable in such an environment to consider the first colon to be a
host delimiter only if the namestring contains a semicolon? Since it
would be unusual to want to use a namestring consisting of only a host
name, that could be a useful way of avoiding the ambiguity.
On first blush I like this idea. Maybe we can work out something along
these lines. I'd be worried about making the rules too complicated to
understand, though.
Date: Tue, 6 Jun 89 18:08:42 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
I would prefer to use "#" as the version prefix. More than once I've
been annoyed when using Symbolics pathnames to not be able to specify a
version without also specifying the type.
My preference is to minimize the use of special characters. I'm not
sure the syntax matters very much so long as we all agree on it so our
programs can interchange logical pathnames, but I don't want the syntax
to appear too complicated and intimidating. I don't think the ability
to specify a version by itself in a namestring is needed for the
intended uses of logical pathnames.
The 12-character limit doesn't seem to have any clear significance.
Since it is common for older file systems to have an 8-character limit
for file names, maybe it would be more meaningful to say that names can
be any length, but only the first 8 characters are guaranteed to be
significant on all implementations.
The particular numbers came from consideration of the 14-character-max
version of Unix, I believe.
I think these length limits were a mistake, and I propose to remove them in
version 3 of the proposal. It is always up to the person who writes the
translation rules for a particular logical pathname host to a particular
physical file system to make sure that the pathnames that are going to be
used translate to valid pathnames for the particular file system.
> There is no device, so the device component of a logical pathname is
> always :UNSPECIFIC. No other component can be :UNSPECIFIC.
I presume you mean that the standard doesn't specify any portable
meaning for an :UNSPECIFIC component, and don't intend to rule out its
use in generic pathnames as an extension?
What's a generic pathname?
I think I meant what I said, which is that no component of a logical pathname
other than the device can ever be :UNSPECIFIC. If that's the wrong thing,
okay, but let's hear an argument why it's wrong. Remember that logical
pathnames don't have to be able to represent all features of all file systems,
they just have to do what's needed for portable naming of program and data
files within a program.
> DEFINE-LOGICAL-PATHNAME-TRANSLATIONS host translations &key [Function]
>
> Define a logical pathname host named <host> (a string or a symbol which
> is coerced to a string). <translations> is a list of translations.
> Each translation is a list of from-wildcard and to-wildcard.
> From-wildcard must be a logical pathname or a string coercible to a
> logical pathname.
Could we say
... coercible to a logical pathname using "<host>:" as the
default pathname.
so that the host doesn't have to be explicitly supplied every time?
That seems like probably a good idea, let me think it over.
> ... To-wildcard must be a physical pathname or a
> coercible to a physical pathname.
Is there any reason to not permit this to be another logical pathname?
Yes, it's too complicated to define what it means and not obviously useful
for anything (as far as I can see).
> There are no keyword arguments specified by this standard, but any
> implementation extensions are provided as keyword arguments or as
> translations with more than two elements.
An extension I would like to have is the ability to specify what syntax
will be used for parsing the name strings. If I'm using logical
pathnames for my own convenience, rather than portability, then I would
like to be able to use whatever pathname syntax I like the most.
I don't understand, could you be more specific?
> Current practice:
The Explorer also has a comparable logical pathname facility, although
the translation mechanism is unfortunately less general than proposed
here. The namestring syntax used is slightly different:
host ":" [{directory "."}* directory ";"] [name] ["." type] ["#" version]
The newest version is indicated by ">" instead of "newest".
I'd like to minimize the use of special characters.
∂12-Jun-89 1619 CL-Cleanup-mailer Re: Issue: PATHNAME-WILD (version 5)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 12 Jun 89 16:19:39 PDT
Received: by ti.com id AA05524; Mon, 12 Jun 89 18:19:13 CDT
Received: from Kelvin by tilde id AA19433; Mon, 12 Jun 89 18:05:57 CDT
Message-Id: <2822684717-5627457@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 12 Jun 89 18:05:17 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
CL-Cleanup@sail.stanford.edu
Subject: Re: Issue: PATHNAME-WILD (version 5)
In-Reply-To: Msg of Mon, 12 Jun 89 18:24 EDT from David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> The Explorer permits DELETE-FILE on a wild pathname, meaning to delete
> all files that match.
>
> I don't think this should be a mandated feature, but we can add it to current
> practice. Do you think this feature of the Explorer is good or a wart? I.e.
> would you like the proposal to say that the consequences are unspecified, or
> would you like the proposal to require the Explorer to change?
I think it's a useful feature (especially on a Lisp Machine where Lisp
is the operating system command language); I'd prefer "consequences
are unspecified" so that this would be a permissible extension.
∂12-Jun-89 1922 CL-Cleanup-mailer Re: Issue: PATHNAME-LOGICAL (version 2)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 12 Jun 89 19:22:05 PDT
Received: by ti.com id AA06805; Mon, 12 Jun 89 21:22:13 CDT
Received: from Kelvin by tilde id AA24410; Mon, 12 Jun 89 21:01:51 CDT
Message-Id: <2822695273-6261691@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 12 Jun 89 21:01:13 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
CL-Cleanup@sail.stanford.edu
Subject: Re: Issue: PATHNAME-LOGICAL (version 2)
In-Reply-To: Msg of Mon, 12 Jun 89 19:02 EDT from David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> I think these length limits were a mistake, and I propose to remove them in
> version 3 of the proposal. It is always up to the person who writes the
> translation rules for a particular logical pathname host to a particular
> physical file system to make sure that the pathnames that are going to be
> used translate to valid pathnames for the particular file system.
That's true for logical directory names, but typically you would want to
specify translations just for the host and directory, and pass the file
names through. If I'm trying to install a software package that came from
somewhere else, I wouldn't want to have to write a translation for every
individual file just because the author used abnormally long file names
and thought they were being portable. Besides, I might not even know the
names of all the files that the program might generate internally.
> > There is no device, so the device component of a logical pathname is
> > always :UNSPECIFIC. No other component can be :UNSPECIFIC.
>
> I presume you mean that the standard doesn't specify any portable
> meaning for an :UNSPECIFIC component, and don't intend to rule out its
> use in generic pathnames as an extension?
>
> What's a generic pathname?
As returned by: (SEND (PATHNAME ...) :GENERIC-PATHNAME)
[I don't expect that to be meaningful to anyone other than Lisp Machine
programmers.] We use :UNSPECIFIC in the type and version slots of generic
pathnames; I see now that Symbolics uses NIL there instead.
> I think I meant what I said, which is that no component of a logical pathname
> other than the device can ever be :UNSPECIFIC. If that's the wrong thing,
> okay, but let's hear an argument why it's wrong.
My concern is that the Explorer does have a use for :UNSPECIFIC type and
version in pathnames, including logical pathnames. I won't argue that it
was a good idea to do it that way; it probably wasn't, but it would be
difficult to change now. If the standard were to be interpreted
to mean that we can't do that, then we would need to have an internal
logical pathname type in addition to the standard one, which would be sure
to keep everyone confused.
All I'm asking for is to not put that restriction in language too strong;
I think we will be OK with anything less than "signals an error".
> > ... To-wildcard must be a physical pathname or a
> > coercible to a physical pathname.
>
> Is there any reason to not permit this to be another logical pathname?
>
> Yes, it's too complicated to define what it means ...
I just expected that TRANSLATE-LOGICAL-PATHNAME would repeat until it
produces a non-logical pathname. I see now, though, that the second and
third values returned would be a problem. Suppose we said that
DEFINE-LOGICAL-PATHNAME-TRANSLATIONS calls TRANSLATE-LOGICAL-PATHNAME on
each of the <to-wildcard> values to force them to be physical pathnames?
> ... and not obviously useful
> for anything (as far as I can see).
The point is that I should be able to use a pathname for nearly anything I
want without needing to know whether it is physical or logical. If you
want an example, suppose the site administrator tells me that he has
created a directory "USERS:GRAY;" for me to use on some central name
server, and I then want to create a logical directory for some large
program of mine so that I can type "GIZMO:DATA;FOO" instead of
"USERS:GRAY;GIZMO;DATA;FOO". Why should should I need to know or care
whether "USERS:" is a physical or logical host? If you are thinking "but
logical pathnames have a different namestring syntax", that is not
necessarily true; on the Explorer, the local file system and logical
pathnames use the same syntax, which we find to be very convenient.
> > There are no keyword arguments specified by this standard, but any
> > implementation extensions are provided as keyword arguments or as
> > translations with more than two elements.
>
> An extension I would like to have is the ability to specify what syntax
> will be used for parsing the name strings. If I'm using logical
> pathnames for my own convenience, rather than portability, then I would
> like to be able to use whatever pathname syntax I like the most.
>
> I don't understand, could you be more specific?
[This point is just an aside, not pertinent to the standard. I mention it
because it is the only capability that I have wished to have in logical
pathnames that isn't covered by your proposal, so I'm pleased that it
could still be done as an extension.]
A logical host defines two things:
1. How to parse a namestring into a pathname object.
2. How to translate a pathname into a physical pathname.
Why not be able to specify both parts instead of being stuck with a fixed
namestring syntax? For example, I use a logical host to access my files
on the VAX just because I like the Explorer pathname syntax better than
the VMS syntax. If someone else was a Unix fan, they might want to be
able to use Unix syntax for their logical namestrings. Thus I would
envision being able to do something like
(define-logical-pathname-translations "mine"
'(("mine:/data/*.*" "vax:sys$user:[who.data]*.*"))
:parser #'parse-unix-namestring)
∂13-Jun-89 0755 CL-Cleanup-mailer Re: Issue: PATHNAME-WILD (version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 13 Jun 89 07:55:09 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 610282; 13 Jun 89 10:55:34 EDT
Date: Tue, 13 Jun 89 10:56 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-WILD (version 5)
To: David N Gray <Gray@DSG.csc.ti.com>, Gray@Kelvin.csc.ti.com
cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>, CL-Cleanup@sail.stanford.edu
In-Reply-To: <2822684717-5627457@Kelvin>
Message-ID: <19890613145601.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 12 Jun 89 18:05:17 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
> The Explorer permits DELETE-FILE on a wild pathname, meaning to delete
> all files that match.
>
> I don't think this should be a mandated feature, but we can add it to current
> practice. Do you think this feature of the Explorer is good or a wart? I.e.
> would you like the proposal to say that the consequences are unspecified, or
> would you like the proposal to require the Explorer to change?
I think it's a useful feature (especially on a Lisp Machine where Lisp
is the operating system command language); I'd prefer "consequences
are unspecified" so that this would be a permissible extension.
OK.
∂13-Jun-89 0906 CL-Cleanup-mailer Re: Issue: PATHNAME-WILD (version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Jun 89 09:06:36 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 13 JUN 89 09:03:01 PDT
Date: 13 Jun 89 09:01 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-WILD (version 5)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Tue, 13 Jun 89 10:56 EDT
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: David N Gray <Gray@DSG.csc.ti.com>, Gray@Kelvin.csc.ti.com, Sandra J
Loosemore <sandra%defun@cs.utah.edu>, CL-Cleanup@sail.stanford.edu
Message-ID: <890613-090301-15730@Xerox>
I'm opposed to "little" "permissible extensions". It weakens the
standard, and hardly is anyone's "competitive advantage". Let the explorer
say DELETE-ALL-FILES-MATCHING. Or even EXPLORER:DELETE-FILES.
∂13-Jun-89 0936 CL-Cleanup-mailer Re: Issue: PATHNAME-WILD (version 5)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Jun 89 09:36:43 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA20822; Tue, 13 Jun 89 10:36:54 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA22421; Tue, 13 Jun 89 10:36:52 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906131636.AA22421@defun.utah.edu>
Date: Tue, 13 Jun 89 10:36:49 MDT
Subject: Re: Issue: PATHNAME-WILD (version 5)
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
David N Gray <Gray@DSG.csc.ti.com>, CL-Cleanup@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Mon, 12 Jun 89 18:24 EDT
I'll try again to explain my confusion (!) about TRANSLATE-PATHNAME.
I think a large part of the problem is that I just don't understand
what the motivation is for making this function as complicated as it
is.
My understanding is that this function is actually performing *two*
distinct operations: first, it performs a pattern match on
<from-wildcard> and <source>; and then it combines <to-wildcard> with
the result of that operation in a kind of merging procedure that fills
in wildcard fields as well as empty fields. My confusion is about why
these two operations have been glued together like this instead of
being made into two separate primitives. It seems like the merging
operation by itself would be quite useful, but I'm having a hard time
imagining an example where you really need the combined operation.
(The rationale section doesn't address this, and it seems like the
RENAME-FILES example could be accomplished with only the merging
primitive.) Is reversibility a property of the matching operation or
the merging operation, or both? Perhaps if the combined functionality
and the whole business about reversibility are only needed to support
logical pathnames, they should be made part of that proposal instead?
After giving this proposal another reading, I have a two additional
unrelated comments. First, WILD-PATHNAME-P and PATHNAME-MATCH-P ought
to be allowed to return "true" instead of T. Second, I think that if
we allow DELETE-FILE not to signal an error when given a wildcard
pathname, that RENAME-FILE also ought to be allowed not to signal an
error.
-Sandra
-------
∂13-Jun-89 1148 CL-Cleanup-mailer Re: Issue: PATHNAME-WILD (version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 13 Jun 89 11:48:17 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 610559; 13 Jun 89 14:49:57 EDT
Date: Tue, 13 Jun 89 14:50 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-WILD (version 5)
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: David N Gray <Gray@DSG.csc.ti.com>, CL-Cleanup@sail.stanford.edu, Gray@Kelvin.csc.ti.com
In-Reply-To: <8906131636.AA22421@defun.utah.edu>
Message-ID: <19890613185018.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 13 Jun 89 10:36:49 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
I'll try again to explain my confusion (!) about TRANSLATE-PATHNAME.
I think a large part of the problem is that I just don't understand
what the motivation is for making this function as complicated as it
is.
Thanks for continuing to pursue this, Sandra.
My understanding is that this function is actually performing *two*
distinct operations: first, it performs a pattern match on
<from-wildcard> and <source>; and then it combines <to-wildcard> with
the result of that operation in a kind of merging procedure that fills
in wildcard fields as well as empty fields.
That's accurate.
My confusion is about why
these two operations have been glued together like this instead of
being made into two separate primitives.
Because some new object would have to be invented to carry the result of
the first operation into the second operation. This would represent the
correspondence between the from-wildcard and the source in some way. In
typical implementations, this is currently represented as flow of control
inside the TRANSLATE-PATHNAME function and functions that it calls. I
wouldn't want to introduce this complicated new pathname-correspondence
object if there isn't really a need to get the first primitive by itself.
Think about (using Unix syntax):
(translate-pathname "/usr/dmr/hacks/frob.l"
"/usr/d*/hacks/*.l"
"/usr/d*/backup/hacks/backup-*.l")
for which the answer is (assuming the wildcard conventions used by the
Unix on which I tried this):
"/usr/dmr/backup/hacks/backup-frob.l"
Now think about:
(translate-pathname "/usr/dmr/hacks/frob.l"
"/usr/d*/hacks/fr*.l"
"/usr/d*/backup/hacks/backup-*.l")
for which the answer is
"/usr/dmr/backup/hacks/backup-ob.l"
Your second primitive sees only the first and third arguments, so it
has no way to distinguish these two cases. To separate the primitives,
the first one would have to output something telling you that in the
first case, "frob" matched the wildcard, while in the second case,
"ob" matched the wildcard. Should this example go into the proposal?
It seems like the merging
operation by itself would be quite useful,
I agree that it's useful. It's available as TRANSLATE-PATHNAME with the
two wildcard pathname arguments the same, isn't it? I don't see how the
matching primitive could be used by itself.
but I'm having a hard time
imagining an example where you really need the combined operation.
(The rationale section doesn't address this, and it seems like the
RENAME-FILES example could be accomplished with only the merging
primitive.)
I haven't been able to figure out how you think the RENAME-FILES example
can be done with only the merging half. Maybe you didn't think about any
cases where the source file name has a partially wild component ("foo*"
rather than "*")? There were two of those in the examples, but they weren't
very clear because the target file name had a full wild component in both.
I should should concoct another example to clarify this. I clearly have a
lot of trouble coming up with examples that cover all the cases for these
things.
Is reversibility a property of the matching operation or
the merging operation, or both?
I don't know, probably both, but it depends on exactly what you had in mind
as the boundary between the two operations.
Perhaps if the combined functionality
and the whole business about reversibility are only needed to support
logical pathnames, they should be made part of that proposal instead?
It's very hard to know how to modularize these proposals. I've heard
everything from "put all pathname stuff into a single omnibus proposal
so we can understand it as a unit", to "break each feature into a
separate proposal so we can address it separately". In the face of
that, I'm just guessing at the modularity. I don't know about the
reversible part, but everything else is useful independent of logical
pathnames.
After giving this proposal another reading, I have a two additional
unrelated comments. First, WILD-PATHNAME-P and PATHNAME-MATCH-P ought
to be allowed to return "true" instead of T.
I think they did in an earlier version, and some commentor made me change
it to T, so as to make the language less ambiguous. Did you have a specific
useful value in mind for them to return? If so, maybe we could just specify
that that is what they return. If not, let's stick with T.
Second, I think that if
we allow DELETE-FILE not to signal an error when given a wildcard
pathname, that RENAME-FILE also ought to be allowed not to signal an
error.
Good point.
∂13-Jun-89 1155 CL-Cleanup-mailer Re: Issue: PATHNAME-LOGICAL (version 2)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Jun 89 11:55:28 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA24397; Tue, 13 Jun 89 12:54:13 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA22473; Tue, 13 Jun 89 12:54:08 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906131854.AA22473@defun.utah.edu>
Date: Tue, 13 Jun 89 12:54:06 MDT
Subject: Re: Issue: PATHNAME-LOGICAL (version 2)
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Richard Mlynarik <Mly@AI.AI.MIT.EDU>,
Sandra J Loosemore <sandra%defun@cs.utah.edu>,
Gail Zacharias <gz@spt.entity.com>, masinter.pa@Xerox.COM,
David N Gray <Gray@DSG.csc.ti.com>, CL-Cleanup@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Mon, 12 Jun 89 19:02 EDT
Just a few short comments:
> I think these length limits were a mistake, and I propose to remove them
> in version 3 of the proposal.
Sounds good. Actually, I think that a logical pathname should permit any
values that are hypothetically valid (under PATHNAME-COMPONENT-VALUE) as
components.
> However, the typical
> use of versions is such that on a file system without versions, people
> would rather just store one version, and not specify translations that
> will preserve the version information by encoding it in the name. This
> is different from the typical use of types or directories, where the
> files with different values in those components are truly distinct and
> everything would break if you only kept one of them.
This makes sense to me, but probably ought to be included somewhere in
the proposal as a rationale.
> I thought it said somewhere that PATHNAME-LOGICAL cannot pass if
> PATHNAME-WILD fails.
It does, but it's way down in the discussion section. (It happened
that I originally read this writeup before the one for PATHNAME-WILD
and I was very confused by the references to TRANSLATE-PATHNAME and
PATHNAME-MATCH-P until I recognized that they were from another issue
I hadn't seen yet.) As you've noted yourself in connection with some
other issues, a lot of people don't make it to the end of the writeup.
> I could have proposed that logical pathnames always use a specific naming
> convention for compiled files, as I did for source files, but for compiled
> files it seemed better to let the implementation control the name. Do
> you think a different approach should have been taken, or did you just
> want to see this proposal split into parts?
If there is going to be a convention for the name of source files, I
would rather see a similar convention adopted for the name of compiled
files.
Perhaps I should add a little here about how we handled pathnames
while working on porting PSL to various machines, including the
infamous Cray. First, we used variables as I outlined in my previous
message to keep track of "places" and "file types" to look for library
files, instead of using literal namestrings all over the place. The
variables were initialized in a separate configuration file. Second,
we had the file open function do its own translation to take care of
mapping pathnames onto namestrings that were recognizable to the host
file system; this is where the namestring got mangled to account for
case canonicalization and truncation appropriate to that host, if
there wasn't a specific mapping for that filename known. In effect,
we treated all pathnames as logical pathnames! Over time, PSL has
gravitated towards using Unix filename syntax for "logical"
namestrings.
-Sandra
-------
∂13-Jun-89 1255 CL-Cleanup-mailer Re: Issue: PATHNAME-WILD (version 5)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Jun 89 12:53:44 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA26121; Tue, 13 Jun 89 13:53:50 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA22515; Tue, 13 Jun 89 13:53:44 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906131953.AA22515@defun.utah.edu>
Date: Tue, 13 Jun 89 13:53:43 MDT
Subject: Re: Issue: PATHNAME-WILD (version 5)
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
David N Gray <Gray@DSG.csc.ti.com>, CL-Cleanup@sail.stanford.edu,
Gray@Kelvin.csc.ti.com
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 13 Jun 89 14:50 EDT
Your additional example has suddenly made it clear to me that I'm even
more confused than I thought I was, and that one of the reasons I'm
confused is the vagueness of the terminology in the proposal. It
seems clear from this example that my interpretation of the terms
"field" and "portion that matches" is not what you really had in mind.
Can you define these terms more precisely and perhaps annotate the
other examples to explain what exactly the "field" and "portion" are?
You seem to be interpreting "portion" to mean "the part that matches
the *" but I'm not at all clear how that would extend to a more
complicated wildcard pattern like a regular expression.
> I think they did in an earlier version, and some commentor made me change
> it to T, so as to make the language less ambiguous. Did you have a specific
> useful value in mind for them to return? If so, maybe we could just specify
> that that is what they return. If not, let's stick with T.
Well, I thought that PATHNAME-MATCH-P might conceivably return some
kind of an object representing the "portion that matches". But more
generally, all the other predicates in the language that I can think
of are defined to either return "true" or NIL. Also, in some
implementations it's slightly more efficient to return an argument
instead of T, for example.
-Sandra
-------
∂13-Jun-89 1315 CL-Cleanup-mailer Re: Issue: PATHNAME-WILD (version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 13 Jun 89 13:15:29 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 610672; 13 Jun 89 16:16:39 EDT
Date: Tue, 13 Jun 89 16:17 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-WILD (version 5)
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: David N Gray <Gray@DSG.csc.ti.com>, CL-Cleanup@sail.stanford.edu, Gray@Kelvin.csc.ti.com
In-Reply-To: <8906131953.AA22515@defun.utah.edu>
Message-ID: <19890613201703.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 13 Jun 89 13:53:43 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
....I'm not at all clear how that would extend to a more
complicated wildcard pattern like a regular expression.
The person who added regular expressions would have to define how they
work with the various pathname functions. There's no way that the
Common Lisp language specification can define that.
I'll respond to the rest of your message later.
∂13-Jun-89 1516 CL-Cleanup-mailer Issue: BIT-ARRAY-FUNCTIONS (Version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 13 Jun 89 15:16:35 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 610803; 13 Jun 89 18:18:06 EDT
Date: Tue, 13 Jun 89 18:17 EDT
From: Kim Barrett <IIM@ECLA.USC.EDU>
Sender: KMP@STONY-BROOK.SCRC.Symbolics.COM
Subject: Issue: BIT-ARRAY-FUNCTIONS (Version 5)
To: CL-Cleanup@SAIL.Stanford.EDU
Comments: Received from Kim Barrett by KMP on MSDOS floppy disk via US Mail
Message-ID: <19890613221755.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Of the two proposals, I prefer ADD. I agree that allowing differing
dimensions for the arguments to these functions is important. Because
of the current requirement that they have equal dimensions I end up
almost never using them.
I think BIT-EQUAL might be a more consistent name, because of
STRING-EQUAL, but that's a minor quibble. What should BIT-EQUALP do
with fill-pointers? EQUAL and EQUALP are limited by the fill-pointer,
so probably this should be too.
Since I believe we added the COMPLEMENT function at the Hawaii meeting
(during the big TEST-NOT-IF-NOT debate), optimize (COMPLEMENT #'ZEROP) too.
∂13-Jun-89 1517 CL-Cleanup-mailer Issue: DATA-IO (Version 6)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 13 Jun 89 15:17:03 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 610805; 13 Jun 89 18:18:52 EDT
Date: Tue, 13 Jun 89 18:18 EDT
From: Kim Barrett <IIM@ECLA.USC.EDU>
Sender: KMP@STONY-BROOK.SCRC.Symbolics.COM
Subject: Issue: DATA-IO (Version 6)
To: CL-Cleanup@SAIL.Stanford.EDU
Comments: Received from Kim Barrett by KMP on MSDOS floppy disk via US Mail
Message-ID: <19890613221841.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Ok.
∂13-Jun-89 1518 CL-Cleanup-mailer Issue: FLOAT-UNDERFLOW (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 13 Jun 89 15:18:08 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 610807; 13 Jun 89 18:19:59 EDT
Date: Tue, 13 Jun 89 18:19 EDT
From: Kim Barrett <IIM@ECLA.USC.EDU>
Sender: KMP@STONY-BROOK.SCRC.Symbolics.COM
Subject: Issue: FLOAT-UNDERFLOW (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Comments: Received from Kim Barrett by KMP on MSDOS floppy disk via US Mail
Message-ID: <19890613221949.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Mostly ok.
Fix C-Y bug. FLOATING-POINT-OVERFLOW signaled when a computation overflows,
not underflows.
I think changing "should signal" to "signals" is likely to generate too much
heat for what I see as an otherwise pretty uncontroversial proposal. Even
"should signal" may be too strong.
∂13-Jun-89 1519 CL-Cleanup-mailer Issue: MAP-INTO (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 13 Jun 89 15:18:58 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 610809; 13 Jun 89 18:20:49 EDT
Date: Tue, 13 Jun 89 18:20 EDT
From: Kim Barrett <IIM@ECLA.USC.EDU>
Sender: KMP@STONY-BROOK.SCRC.Symbolics.COM
Subject: Issue: MAP-INTO (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Comments: Received from Kim Barrett by KMP on MSDOS floppy disk via US Mail
Message-ID: <19890613222039.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
I don't have any strong objections to this. The only problem is that this
isn't really the function I want. The function I really want is a variation on
REPLACE, with a function applied to the successive elements from the source
sequence and the result of the function being stored into the destination
sequence. Probably the simplest way to add this to the language would be to
add a keyword to REPLACE (say :transform, though I don't have any strong
preference for any particular name) which defaults to IDENTITY. I suppose I
could write this up as a seperate proposal, but I really don't have the time,
especially if I have to argue that it isn't just a puppy.
The description of MAP-INTO should be changed to be consistent with MAP and
friends, ie.
MAP-INTO result-sequence function sequence &rest more-sequences [Function]
rather than
MAP-INTO result-sequence function &rest sequences [Function]
∂13-Jun-89 1520 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-CASE (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 13 Jun 89 15:20:08 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 610813; 13 Jun 89 18:21:56 EDT
Date: Tue, 13 Jun 89 18:21 EDT
From: Kim Barrett <IIM@ECLA.USC.EDU>
Sender: KMP@STONY-BROOK.SCRC.Symbolics.COM
Subject: Issue: PATHNAME-COMPONENT-CASE (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
Comments: Received from Kim Barrett by KMP on MSDOS floppy disk via US Mail
Message-ID: <19890613222146.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
I had one person here who's initial reaction was against :COMMON as the default
:CASE, but I think it's the right thing. At first I thought that perhaps the
:COMMON convention was backward, but after reviewing the file systems I've
encountered, I agree that the choice is pretty much arbitrary, and consistency
with Lisp symbols is as good a reason for choosing a direction on this as any.
(Of course, the READ-CASE proposal might change this argument out from under.)
∂13-Jun-89 1520 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-VALUE (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 13 Jun 89 15:20:43 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 610814; 13 Jun 89 18:22:25 EDT
Date: Tue, 13 Jun 89 18:22 EDT
From: Kim Barrett <IIM@ECLA.USC.EDU>
Sender: KMP@STONY-BROOK.SCRC.Symbolics.COM
Subject: Issue: PATHNAME-COMPONENT-VALUE (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Comments: Received from Kim Barrett by KMP on MSDOS floppy disk via US Mail
Message-ID: <19890613222215.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Ok.
∂13-Jun-89 1523 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 6)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 13 Jun 89 15:23:12 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 610822; 13 Jun 89 18:24:56 EDT
Date: Tue, 13 Jun 89 18:24 EDT
From: Kim Barrett <IIM@ECLA.USC.EDU>
Sender: KMP@STONY-BROOK.SCRC.Symbolics.COM
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 6)
To: CL-Cleanup@SAIL.Stanford.EDU
Comments: Received from Kim Barrett by KMP on MSDOS floppy disk via US Mail
Message-ID: <19890613222446.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Yes. For current practice, IIM does something similar. The keywords are
different, and only :BACK supported. I believe the keyword mapping is
:ABSOLUTE :ABSOLUTE-DIRECTORY
:RELATIVE (no leading keyword)
:BACK :SUPER-DIRECTORY
The addition of the :RELATIVE keyword is probably cleaner, since it means that
there is always a keyword at the head of the list, and a test for a relative
directory is (eq (car directory) :relative) rather than something like
(and directory (not (symbolp (car directory)))).
The interaction between :BACK and :WILD-INFERIORS doesn't seem clear. I
believe this is a case where :BACK and the thing preceding it cannot be
spliced out (you can end up with (... :WILD-INFERIORS :BACK ...). Also,
(:ABSOLUTE :BACK ...) should probably signal an error.
∂13-Jun-89 1525 CL-Cleanup-mailer Issue: PATHNAME-LOGICAL (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 13 Jun 89 15:21:35 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 610818; 13 Jun 89 18:23:22 EDT
Date: Tue, 13 Jun 89 18:23 EDT
From: Kim Barrett <IIM@ECLA.USC.EDU>
Sender: KMP@STONY-BROOK.SCRC.Symbolics.COM
Subject: Issue: PATHNAME-LOGICAL (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Comments: Received from Kim Barrett by KMP on MSDOS floppy disk via US Mail
Message-ID: <19890613222312.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
Is there really any need to allow integers for version numbers here? My
experience has been that anytime I've used logical pathnames in a place where I
actually needed them (as opposed to just typing, so I don't have to keep
worrying about different syntaxes), using explicit version numbers was a bad
idea even when dealing with a file system that supported them.
Re: LOGICAL-PATHNAME type. Why? I think there may be a hidden assumption
about implementation technique here, namely that pathnames for different file
system types will be different subtypes of PATHNAME. I don't see anything else
in the proposal that needs this, since a "logical pathname" could also be
defined as a pathname whose host is a logical pathname host.
I'm somewhat concerned about mapping logical pathnames into real file systems
which don't support some or all of the capabilities of logical pathnames. I'm
not too concerned about file systems which don't support heirarchical
directories, having not had the misfortune to encounter such a beast in a long
time. Just out of curiosity, are there any such in common use above the micro
level (I've heard rumors of old IBM mainframe OS'es)? As far as version
numbers, see above.
The main point I'm concerned about is the definition of a word.
1. Hyphens: I think hyphens can be dealt with fairly easily by translating them
into some non-alphanumeric supported by the file system, underscore being a
likely candidate. Basically, the solution here is documentation.
2. Wild cards: Some file systems don't have very general support for wild
cards. For example, MS-DOS effectively ignores anything following the first
"*" in a file name, limiting matches to a prefix plus wild-card suffix. Of
course, a Common Lisp implementation could add a layer of filtering on top of
this, so I don't think this is so bad.
3. 12 character names: This is the main point I have trouble with. There are a
lot of file systems out there which don't support 12 character names. MS-DOS
has a limit of 8, except the type which is limited to 3. I believe ITS is
limited to 6.
The problem is that the translation algorithm must be easy to use by people,
not just computers (specifically the Lisp implementation).
Part of the solution here may again be documentation. As a suggestion, for
each of the system types described under PATHNAME-SYSTEM-TYPE (see that issue)
in the standard, the logical pathname mapping algorithm could also be
specified. (Of course, this requires that people be able to agree to such).
Alternatively, add some verbiage to the description of logical pathnames saying
that some file systems are limited in the actual length of their logical
pathname words, and names should be chosen appropriately. It may be safe to
"require" that at least 6 characters will be used, and treat these like
function and variable names in some languages which allow you to have long
names but which ignore all but the first n characters. I'm actually somewhat
inclined toward the latter solution, since people seem to be able to live with
it in programming languages (though perhaps not being ecstatic about it) and it
frequently avoids the need to have to count characters, and if the number is
small (like 6) it is easier to "eyeball" whether you are over the limit than if
it is a larger number (like 12) (see the note on the examples below).
I suppose if you have PATHNAME-SYSTEM-TYPE you can always conditionalize your
pathnames somewhat depending on the file system type (ugly, and somewhat
defeats the point of this proposal).
There may be an ambiguity in the logical pathname description, namely is ".5" a
pathname with version == 5 and everything else unspecified, or is the type ==
"5" and everything else is unspecified.
I was wondering why add a function like COMPILE-FILE-PATHNAME, rather than just
defining another canonical type analogous to "LISP", like "BIN" or "FASL" or
some other name. I suppose it avoids arguments about what the 'right' name is,
although I personally don't care about the precise name used. The only reason
I can think of is to allow COMPILE-FILE to generate a name that isn't just the
result of something like
(merge-pathnames output-file (make-pathname :type *compiled-file-type*
:defaults input-file))
As a note, "A more complex example" contains a violation of the 12 character
limit: "DOCUMENTATION" is 13 characters long.
∂13-Jun-89 1526 CL-Cleanup-mailer Issue: STRING-COERCION (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 13 Jun 89 15:25:36 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 610830; 13 Jun 89 18:27:12 EDT
Date: Tue, 13 Jun 89 18:27 EDT
From: Kim Barrett <IIM@ECLA.USC.EDU>
Sender: KMP@STONY-BROOK.SCRC.Symbolics.COM
Subject: Issue: STRING-COERCION (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Comments: Received from Kim Barrett by KMP on MSDOS floppy disk via US Mail
Message-ID: <19890613222702.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Ok.
∂13-Jun-89 1528 CL-Cleanup-mailer General pathname comments
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 13 Jun 89 15:26:58 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 610831; 13 Jun 89 18:28:38 EDT
Date: Tue, 13 Jun 89 18:28 EDT
From: Kim Barrett <IIM@ECLA.USC.EDU>
Sender: KMP@STONY-BROOK.SCRC.Symbolics.COM
Subject: General pathname comments
To: CL-Cleanup@SAIL.Stanford.EDU
Comments: Received from Kim Barrett by KMP on MSDOS floppy disk via US Mail
Message-ID: <19890613222827.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
None of this should be taken as actual proposals. I'm mostly pointing out some
places where I think there are still problems.
1. Something that always bothered me about the Symbolics pathname system, which
seems to be unstated but present in these proposals, is the mechanism for
parsing strings to pathnames. There seems to be an unstated assumption that
the parsing will try to find a host specification in the string and parse
according to the syntax of that host. I believe it is wrong to try to parse
the string in order to determine how to parse the string. That's what the Host
and Defaults arguments for PARSE-NAMESTRING are for, and I think it would be
better to clarify that, and make recommendations about specifying arguments to
PARSE-NAMESTRING or binding *DEFAULT-PATHNAME-DEFAULTS*.
As an example, consider a namestring of "SYS:FOO.LISP", with
*DEFAULT-PATHNAME-DEFAULTS* bound to a pathname whose syntax specifies that the
device is followed by a ":" (TOPS-20 satisfies this, but I seem to remember
there is an ambiguity in TOPS-20 pathnames, at least in the Symbolics
implementation, in that the host is also followed by a ":"). Should this
namestring be parsed into a logical pathname whose host is SYS, or should it be
parsed using the parsing algorithm for the host in
*DEFAULT-PATHNAME-DEFAULTS*?
Of course, I may be completely off base with these comments. But I think not,
based in part on what people claim are reasonable printed representations for
pathnames. Both the #P"..." and #.(PATHNAME "...") printed representations
really require that you can in some way infer the proper parsing algorithm by
looking at the string. Otherwise, changing the value of
*DEFAULT-PATHNAME-DEFAULTS* would break the print/read invertability. I
pointed some of this out in mail a while back when there was some discussion
about the printed representations of pathnames.
2. Perhaps *DEFAULT-PATHNAME-DEFAULTS* should be generalized. I seem to
remember (at least) one of the LispM implementations had per-host defaults.
This might cause problems for figuring out what syntax to use for parsing
though (see 1 above).
3. Something we (IIM) provide is an escape for the parsing (we parse according
to the host or defaults arguments to PARSE-NAMESTRING, unless this escape hatch
is invoked). We chose a syntax that doesn't conflict with the syntax of any
file system we know of, namely using curly braces. If the string begins with a
substring surrounded by curly braces, then that substring specifies the host
whose syntax is to be used to parse the remainder of the string. For example:
namestring := "{MY-TOPS-20}MY-MSDOS:X:<FOO.BAR>BAZ"
(PARSE-NAMESTRING namestring)
=> ;; regardless of the value of *DEFAULT-PATHNAME-DEFAULTS*
#.(PARSE-NAMESTRING "[MY-MSDOS]X:/FOO/BAR/BAZ" "MY-MSDOS")
(NAMESTRING namestring) => "[MY-MSDOS]X:/FOO/BAR/BAZ"
(We put square-brackets around the host in our extension to MSDOS file syntax).
Note that the curly-brace host is only used to determine the algorithm to be
used for parsing, not defaulting or anything like that.
∂13-Jun-89 1528 CL-Cleanup-mailer Issue: PATHNAME-SYSTEM-TYPE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 13 Jun 89 15:24:19 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 610827; 13 Jun 89 18:25:57 EDT
Date: Tue, 13 Jun 89 18:25 EDT
From: Kim Barrett <IIM@ECLA.USC.EDU>
Sender: KMP@STONY-BROOK.SCRC.Symbolics.COM
Subject: Issue: PATHNAME-SYSTEM-TYPE (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Comments: Received from Kim Barrett by KMP on MSDOS floppy disk via US Mail
Message-ID: <19890613222547.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
:ITS ? ;I think some of these are still around.
:MACINTOSH ?
:TENEX ? ;Do any still exist? I briefly used BBN LISP on one.
Any others people want to add?
∂13-Jun-89 1533 CL-Cleanup-mailer Issue: PATHNAME-WILD (Version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 13 Jun 89 15:24:47 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 610828; 13 Jun 89 18:26:24 EDT
Date: Tue, 13 Jun 89 18:26 EDT
From: Kim Barrett <IIM@ECLA.USC.EDU>
Sender: KMP@STONY-BROOK.SCRC.Symbolics.COM
Subject: Issue: PATHNAME-WILD (Version 5)
To: CL-Cleanup@SAIL.Stanford.EDU
Comments: Received from Kim Barrett by KMP on MSDOS floppy disk via US Mail
Message-ID: <19890613222614.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
I don't understand TRANSLATE-PATHNAME. I think I know the intent, but the
description in the proposal is pretty opaque.
∂13-Jun-89 1533 CL-Cleanup-mailer Issue: STREAM-CAPABILITIES (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 13 Jun 89 15:24:59 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 610829; 13 Jun 89 18:26:49 EDT
Date: Tue, 13 Jun 89 18:26 EDT
From: Kim Barrett <IIM@ECLA.USC.EDU>
Sender: KMP@STONY-BROOK.SCRC.Symbolics.COM
Subject: Issue: STREAM-CAPABILITIES (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
Comments: Received from Kim Barrett by KMP on MSDOS floppy disk via US Mail
Message-ID: <19890613222639.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Ok.
∂13-Jun-89 1553 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 13 Jun 89 15:53:25 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 610864; 13 Jun 89 18:55:13 EDT
Date: Tue, 13 Jun 89 18:55 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19890613225538.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Version 5 of this proposal passed with amendments at the January
1989 X3J13 meeting. However, the amendments were found to result
in an inconsistent proposal, and it was also pointed out that some
related problems with simple-arrays were not addressed. Since then
there has been a great deal of private discussion, and review of
various versions of the proposal including ones earlier than 5.
The result is this proposal, which is believed to be acceptable to
everyone and is being offered for a vote in June to replace the
January version that was already voted in.
Issue: ADJUST-ARRAY-NOT-ADJUSTABLE
References: ADJUST-ARRAY (p297), ADJUSTABLE-ARRAY-P (p293),
MAKE-ARRAY (pp286-289), simple arrays (p28, 289),
simple strings with fill pointers (p299)
Category: CLARIFICATION and CHANGE
Edit history: 22-Apr-87, Version 1 by Pitman
15-Nov-88, Versions 2a,2b,2c by Pitman
02-Dec-88, Version 3 by Pitman
11-Jan-89, Version 4 by Pitman
16-Jan-89, Version 5, by Gabriel. Amended at the meeting to shorten.
23-Jan-89, Version 6, by Moon. Shorten without the bug introduced
by the amendment, add clarification of SIMPLE-ARRAY type.
15-Feb-89, Version 7, by Pitman. Minor changes per comments from
RPG and Dalton.
11-Mar-89, Version 8, by Pitman. Change category, add endorsements.
17-Mar-89, Version 9, by Moon, fix wording and examples to make it
clear that the semantics of simple-array is unchanged.
6-Jun-89, Version 10, by Moon and Gabriel, do over.
Problem Description:
There are a number of unclear passages in CLtL related to simple arrays
and adjustable arrays. There is disagreement on precisely how these
passages are to be interpreted, and no one is happy with the fact that
ADJUST-ARRAY works only on an implementation-dependent subset of arrays.
The description of the :ADJUSTABLE option to MAKE-ARRAY on p288 says that
``the argument, if specified and not NIL, indicates that it must be
possible to alter the array's size dynamically after it is created. This
argument defaults to NIL.'' The description of the :ADJUSTABLE option
does not say what MAKE-ARRAY will do if the argument is unsupplied or
explicitly NIL.
The description of ADJUSTABLE-ARRAY-P on p293 says that it is true ``if
the argument (which must be an array) is adjustable, and otherwise
false.'' However, the description of MAKE-ARRAY makes it clear that this
is not necessarily the same as asking if the array was created with
:ADJUSTABLE T. If ADJUSTABLE-ARRAY-P returns NIL, you know that
:ADJUSTABLE NIL was supplied (or no :ADJUSTABLE option was supplied), but
if ADJUSTABLE-ARRAY-P returns T, then there is no information about
whether :ADJUSTABLE was used.
The description of ADJUST-ARRAY on pp297-298 says that it is ``not
permitted to call ADJUST-ARRAY on an array that was not created with the
:ADJUSTABLE option.'' This is inconsistent with ADJUSTABLE-ARRAY-P.
The definition of SIMPLE-ARRAY on p.28 says ``an array that is not
displaced to another array, has no fill pointer, and is not to have its
size adjusted dynamically after creation is called a simple array.''
It is left unclear whether this is an implication or an equivalence,
i.e. whether there can be other simple arrays as well.
CLtL p.299 appears to refer to simple strings with fill pointers,
suggesting that it is an implication, but similar language is used for
equivalences in other parts of CLtL.
Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE:IMPLICIT-COPY)
1. If MAKE-ARRAY is called with the :ADJUSTABLE, :FILL-POINTER,
and :DISPLACED-TO arguments each either unspecified or false, the
resulting array is a simple array. (This just repeats what CLtL
says on page 289, it's here to aid in understanding the next point.)
2. If MAKE-ARRAY is called with one or more of the :ADJUSTABLE,
:FILL-POINTER, or :DISPLACED-TO arguments true, whether the
resulting array is simple is unspecified.
3. It is permitted to call ADJUST-ARRAY on any array. (Remove the
restriction documented at the bottom of p.297.)
4. If ADJUST-ARRAY is applied to an array created with :ADJUSTABLE true,
the array returned is EQ to its first argument. It is not specified
whether ADJUST-ARRAY returns an array EQ to its first argument for any
other arrays. If the array returned by ADJUST-ARRAY is not EQ to its
first argument, the consequences of any reference to the original array
are undefined.
5. The predicate ADJUSTABLE-ARRAY-P is true if and only if ADJUST-ARRAY
will return a value EQ to this array when given this array as its first
argument.
Clarifications and Logical Consequences:
a. There is no specified way to create an array for which ADJUSTABLE-ARRAY-P
definitely returns NIL.
b. There is no specified way to create an array that is non-simple.
c. The definition of SIMPLE-ARRAY on p.28 is taken to be an implication,
not an equivalence. This is either a clarification or a change depending
on one's prior reading of that definition.
d. The meaning of ADJUSTABLE-ARRAY-P is changed.
e. As with such functions as DELETE and NCONC, textbooks should
instruct programmers to be careful to receive the value returned by
ADJUST-ARRAY, as it might not be EQ to the first argument.
Rationale:
Points 3 and 4 eliminate the problem of ADJUST-ARRAY only working on a
subset of arrays, by changing it to work on all arrays. It remains
implementation-dependent whether the array is modified in place or
copied, i.e. whether the result is EQ to the argument, however many other
functions in Common Lisp have similar implementation-dependent behavior.
Implementation-dependent storage allocation or reuse is considered
more benign than implementation-dependent applicability of an operation.
Point 3 recognizes that ADJUST-ARRAY offers features that are offered by
no other function and which are useful in cases involving non-adjustable
arrays (for what amounts to copying). This change would allow an
expression such as:
(SETQ X (ADJUST-ARRAY X ...))
to work reliably. Those desiring the old behavior could do:
(IF (OR (NOT (ADJUSTABLE-ARRAY-P X))
(NOT (EQUAL (ARRAY-RANK X) (LENGTH NEW-DIMENSIONS))))
(ERROR "Array cannot be adjusted."))
to get the old style error checking.
Point 5 recycles the name ADJUSTABLE-ARRAY-P as a test for whether an
array is adjusted in place or by copying.
Point 2 preserves the raison d'etre of simple arrays, which is to provide
a portable interface to implementation-dependent specialized arrays that
trade decreased functionality for faster access. A proposed alternative
was to specify a way to create an array that is guaranteed not to be
simple. This would have made (typep (make-array ...) 'simple-array)
return the same value in all implementations, but would have required
large changes to some implementations and would be of little benefit to
users. Users need to know that certain arrays are simple, so they can
put in declarations and get higher performance, but users have no need to
be able to create arrays that are definitely non-simple (for lower
performance) or definitely non-adjustable.
Examples:
1. The following program is conforming.
(defun double (a)
(adjust-array a (* (length a) 2)))
(double (make-array 30))
2. The following program is conforming. In no implementation is the
type declaration violated.
(let ((a (make-array 100)))
(declare (simple-array a))
(frob a))
3. The following program is non-conforming. The consequences of this
program are undefined because the type declaration is violated in some
implementations.
(let ((a (make-array 100 :adjustable t)))
(declare (simple-array a))
(frob a))
Current Practice:
Every correct CLtL implementation conforms to points 1 and 2. It is
unlikely that any implementation currently exists that conforms to points
3, 4, and 5. Points 3 and 4 involve additions to an implementation to
support the copying form of ADJUST-ARRAY. Point 5 may involve a change
to ADJUSTABLE-ARRAY-P or may be able to use the existing implementation
of the function.
Symbolics Genera makes :ADJUSTABLE NIL arrays adjustable in most cases,
and ignores adjustability in deciding whether an array is a SIMPLE-ARRAY.
The arrays that are internally simple in Symbolics Genera are a different
subset of arrays from the type SIMPLE-ARRAY, because simplicity in that
implementation depends on the rank and total-size as well as on the
fill-pointer and displacement, thus Genera does not use the type
SIMPLE-ARRAY for anything.
Lucid, IIM, Ibuki, and Symbolics Cloe make :ADJUSTABLE NIL arrays
non-adjustable in all cases, and make every array non-simple that CLTL
does not require to be simple.
Macintosh Allegro Common Lisp v1.2 makes :ADJUSTABLE NIL arrays
non-adjustable in all cases, makes all arrays of rank other than 1
non-simple (violating point 1), and makes every array non-simple that
CLTL does not require to be simple.
Cost to Implementors:
The change to ADJUSTABLE-ARRAY-P is easy. The change to ADJUST-ARRAY may
involve some complex coding but should not be a large task. No changes
are required to anything connected with SIMPLE-ARRAY.
Cost to Users:
None in code that does not call ADJUSTABLE-ARRAY-P. This is a fully
upward-compatible change from the user's standpoint.
Benefits:
Programs that use simple arrays and/or adjust arrays will be easier
to port, as the language specification for these features will be
clearer. More programs will be able to call ADJUST-ARRAY, as its use
will not be restricted to a subset of arrays.
Non-Benefits:
Users who expect adjusting arrays created with :ADJUSTABLE NIL to signal
an error would not get the desired signal. A few programs might have
porting problems due to variation among implementations of whether the
result of ADJUST-ARRAY is EQ to the first argument.
Aesthetics:
Most people believe the status quo is unaesthetic. Having an aspect of
the language more clearly specified is an aesthetic improvement.
Allowing ADJUST-ARRAY on all arrays is an aesthetic improvement.
Discussion:
There are at least 110 messages of discussion preceding this version of the
proposal. It does not seem feasible to summarize them here.
Dick Gabriel, Dave Moon, and Guy Steele support this proposal.
∂13-Jun-89 1623 CL-Cleanup-mailer General pathname comments
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 13 Jun 89 16:23:28 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 610884; 13 Jun 89 19:25:10 EDT
Date: Tue, 13 Jun 89 19:25 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: General pathname comments
To: Kim Barrett <IIM@ECLA.USC.EDU>
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19890613222827.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890613232533.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 13 Jun 89 18:28 EDT
From: Kim Barrett <IIM@ECLA.USC.EDU>
None of this should be taken as actual proposals. I'm mostly pointing out some
places where I think there are still problems.
1. Something that always bothered me about the Symbolics pathname system, which
seems to be unstated but present in these proposals, is the mechanism for
parsing strings to pathnames. There seems to be an unstated assumption that
the parsing will try to find a host specification in the string and parse
according to the syntax of that host. I believe it is wrong to try to parse
the string in order to determine how to parse the string. That's what the Host
and Defaults arguments for PARSE-NAMESTRING are for, and I think it would be
better to clarify that, and make recommendations about specifying arguments to
PARSE-NAMESTRING or binding *DEFAULT-PATHNAME-DEFAULTS*.
That's fine for PARSE-NAMESTRING, but Common Lisp has a function PATHNAME that
takes only a namestring, with no argument for a host, and lots of functions are
specified to call it implicitly. So there has to be some way to get a pathname
from just a string. CLtL p.415 refers to the ideas of "manifest host name"
and "explicit host name" (probably the same thing?) in namestrings, but doesn't
define what they are. Nonetheless, it seems clear that there has to be a way
to include host specifications in namestrings, at least in some implementations.
....
Of course, I may be completely off base with these comments. But I think not,
based in part on what people claim are reasonable printed representations for
pathnames. Both the #P"..." and #.(PATHNAME "...") printed representations
really require that you can in some way infer the proper parsing algorithm by
looking at the string. Otherwise, changing the value of
*DEFAULT-PATHNAME-DEFAULTS* would break the print/read invertability. I
pointed some of this out in mail a while back when there was some discussion
about the printed representations of pathnames.
You're right that whatever the printed representation printed for a pathname,
it shouldn't depend on random special variables like *DEFAULT-PATHNAME-DEFAULTS*.
It should contain a "manifest host name."
2. Perhaps *DEFAULT-PATHNAME-DEFAULTS* should be generalized. I seem to
remember (at least) one of the LispM implementations had per-host defaults.
Symbolics pathnames originally worked that way and it was a real disaster.
I would strongly argue against it.
3. Something we (IIM) provide is an escape for the parsing (we parse according
to the host or defaults arguments to PARSE-NAMESTRING, unless this escape hatch
is invoked). We chose a syntax that doesn't conflict with the syntax of any
file system we know of, namely using curly braces. If the string begins with a
substring surrounded by curly braces, then that substring specifies the host
whose syntax is to be used to parse the remainder of the string. For example:
namestring := "{MY-TOPS-20}MY-MSDOS:X:<FOO.BAR>BAZ"
(PARSE-NAMESTRING namestring)
=> ;; regardless of the value of *DEFAULT-PATHNAME-DEFAULTS*
#.(PARSE-NAMESTRING "[MY-MSDOS]X:/FOO/BAR/BAZ" "MY-MSDOS")
(NAMESTRING namestring) => "[MY-MSDOS]X:/FOO/BAR/BAZ"
(We put square-brackets around the host in our extension to MSDOS file syntax).
Note that the curly-brace host is only used to determine the algorithm to be
used for parsing, not defaulting or anything like that.
I don't understand why you would want to parse a pathname in a syntax different
from the syntax of the host you are going to use it with, but I'll defend to the
death your right to do it. In other words I think Common Lisp has to allow some
implementation variance in the syntax of file names, since it depends on criteria
that X3J13 can't know in advance.
∂14-Jun-89 1205 CL-Cleanup-mailer Re: Issue: PATHNAME-LOGICAL (Version 2)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 14 Jun 89 12:05:27 PDT
Received: by ti.com id AA23250; Wed, 14 Jun 89 14:04:58 CDT
Received: from dsg by tilde id AA19193; Wed, 14 Jun 89 13:53:16 CDT
Received: From Kelvin By dsg Via CHAOS-NET With CHAOS-MAIL; Wed, 14 Jun 89 12:26:18 CDT
Message-Id: <2822837265-14792772@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 14 Jun 89 12:27:45 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Kim Barrett <IIM@ECLA.USC.EDU>
Cc: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>,
CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: Issue: PATHNAME-LOGICAL (Version 2)
In-Reply-To: Msg of Tue, 13 Jun 89 18:23 EDT from Kim Barrett <IIM@ECLA.USC.EDU>
> Is there really any need to allow integers for version numbers here? My
> experience has been that anytime I've used logical pathnames in a place where I
> actually needed them (as opposed to just typing, so I don't have to keep
> worrying about different syntaxes), using explicit version numbers was a bad
> idea even when dealing with a file system that supported them.
So what's wrong with using logical pathnames for "just typing"? I think
that inappropriate use of version numbers is an issue of good programming
practice that is no more related to logical pathnames than it is to
physical pathnames.
> Re: LOGICAL-PATHNAME type. Why? I think there may be a hidden assumption
> about implementation technique here, namely that pathnames for different file
> system types will be different subtypes of PATHNAME. I don't see anything else
> in the proposal that needs this, since a "logical pathname" could also be
> defined as a pathname whose host is a logical pathname host.
It would permit methods specialized on LOGICAL-PATHNAME and PATHNAME to
distinguish whether a translation is needed, although I'm not sure that is
really useful since asking for a translation on a physical pathname
doesn't hurt. You may be right that the standard doesn't need to specify
this.
> There may be an ambiguity in the logical pathname description, namely is ".5" a
> pathname with version == 5 and everything else unspecified, or is the type ==
> "5" and everything else is unspecified.
I think that the way the brackets are nested in the syntax makes it
unambiguous that if there is only one dot, it is the type. This could,
however, be confusing for humans.
> I was wondering why add a function like COMPILE-FILE-PATHNAME, rather than just
> defining another canonical type analogous to "LISP", like "BIN" or "FASL" or
> some other name. I suppose it avoids arguments about what the 'right' name is,
> although I personally don't care about the precise name used. The only reason
> I can think of is to allow COMPILE-FILE to generate a name that isn't just the
> result of something like
>
> (merge-pathnames output-file (make-pathname :type *compiled-file-type*
> :defaults input-file))
You also need to be able to merge with an explicit :OUTPUT-FILE argument.
Then there is the question of version number: is it always :NEWEST, or
the same as specified for the input, or the same as the truename of the
input file? What if the input and output are on different hosts and one
supports versions and the other doesn't? On the Explorer, there is a
special variable to control how versions are handled, and the code to
compute the output pathname for COMPILE-FILE is some 60 lines long. So it
is not trivial.
∂14-Jun-89 1444 CL-Cleanup-mailer Re: Issue: PATHNAME-SYSTEM-TYPE (Version 1)
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 14 Jun 89 14:44:02 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa12107; 14 Jun 89 17:44 EDT
Received: from draper.com by RELAY.CS.NET id aa00341; 14 Jun 89 17:40 EDT
Date: Wed, 14 Jun 89 13:14 EDT
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Issue: PATHNAME-SYSTEM-TYPE (Version 1)
To: cl-cleanup@SAIL.STANFORD.EDU
X-VMS-To: CL-CLEANUP,SEB1525
OS's that don't have hierarchical directories:
IBM's MVS and (unless I'm mistaken) VM, which are both very much alive,
don't have hierarchical directories. (Just ask somebody at Lucid.)
- Steve B. (Draper Lab)
∂16-Jun-89 1207 CL-Cleanup-mailer Issue: READ-CASE-SENSITIVITY (Version 3)
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 16 Jun 89 12:07:22 PDT
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP
id aa09199; 16 Jun 89 19:29 BST
Date: Fri, 16 Jun 89 19:35:44 BST
Message-Id: <19558.8906161835@aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: Issue: READ-CASE-SENSITIVITY (Version 3)
To: cl-cleanup@sail.stanford.edu
I am not going to be able to come to the meeting but would
still like to see this issue considered. I wasn't present
for the discussion at the last meeting, but my understanding
is that the committee wanted to see the issue again with
only a single proposal. Unfortunately, I don't know which
proposal (keyword or function) most people prefer.
It has also been remarked that :INVERT is somewhat strange in that it
would have Zebra read as zEBRA; and it was suggested that inversion
should happen only if the entire name were single-case.
Unfortunately, the processing has to happen a character at a time,
because READ has to do it only for characters that are not escaped.
For example, |zebra| should always read as zebra.
Apart from that, very little has been said about this proposal.
I hope that anyone who does have objections will be able to raise
them by mail before the meeting.
Issue: READ-CASE-SENSITIVITY
Forum: Cleanup
References: CLtL p 334 ff: What the Read Function Accepts,
especially p 337, step 8, point 1.
CLtL p 360 ff: The Readtable
COPY-READTABLE (CLtL, p 361)
*PRINT-CASE* (CLtL, p 372)
Category: ADDITION/CHANGE
Edit history: Version 1, 15-Feb-89, by Dalton
Version 2, 23-Mar-89, by Dalton,
(completely new proposal after comments from
Pitman, Gray, Masinter, and R.Tobin@uk.ac.ed)
Version 3, 16-Jun-89, by Dalton
(very minor changes in presentation
and some additions to the discussion)
Problem Description:
The Common Lisp reader always converts unescaped constituent
characters to upper case. (See CLtL, p 337, step 8, point 1.)
This behavior is not always desirable.
1. Lisp applications often use the Lisp reader to read their data.
This is often significantly easier than writing input routines
from scratch, especially if the input can be structured as lists.
However, certain applications want to make use of case distinctions,
and Common Lisp makes this unreasonably difficult. (You must define
every letter as a read macro and have the macro function read the
rest of the symbol, or else you must write a reader from scratch.)
2. Some programming languages distinguish between upper and lower
case in identifiers, and useful conventions are often built around
such distinctions. For example, in C, constants are often written
in upper case and variables in lower. In Mesa(?) and Smalltalk(?),
a capital letter is used to indicate the beginning of a new word
in identifiers made up of several words. In Edinburgh Prolog,
variables begin with upper-case letters and constant symbols do
not. The case-insensitivity of the Common Lisp reader makes
it difficult to use conventions of this sort.
Proposal (READ-CASE-SENSITIVITY:READTABLE-KEYWORDS)
Define a new settable function, (READTABLE-CASE <readtable>) to
control the reader's interpretation of case. The following values
may be given:
:UPCASE -- convert unescaped characters to upper-case, as now.
:DOWNCASE -- convert unescaped characters to lower-case.
:PRESERVE -- don't convert, leaving lower-case letters in lower
case and upper-case characters in upper case.
:INVERT -- convert lower-case to upper and upper-case to lower.
COPY-READTABLE copies the setting of READTABLE-CASE. The value of
READTABLE-CASE for the standard readtable is :UPCASE.
The READTABLE-CASE of a readtable also has significance when
printing. The case in which letters are printed is determined as
follows:
When READ-CASE is :UPCASE, upper-case letters are printed in the
case specified by *PRINT-CASE*.
When READ-CASE is :DOWNCASE, lower-case letters are printed in
the case specified by *PRINT-CASE*.
When READ-CASE is :PRESERVE, letters are printed in their own
case.
When READ-CASE is :INVERT, the case of all letters is inverted.
(The behavior when *PRINT-CASE* is :CAPITALIZE is like :UPCASE for
the first character and :DOWNCASE for the rest.)
The rules for escaping letters are also affected by the READTABLE-CASE.
If *PRINT-ESCAPE* is true, letters are escaped as follows:
When READ-CASE is :UPCASE, all lower-case letters must be escaped.
When READ-CASE is :DOWNCASE, all upper-case letters must be escaped.
Otherwise, no letters need be escaped.
Proposal (READ-CASE-SENSITIVITY:READTABLE-FUNCTION)
Define a new settable function (READTABLE-CHARACTER-TRANSLATION
<readtable>) to control the reader's interpretation of unescaped
constituent characters. The value may be any function of type
(FUNCTION (CHARACTER) CHARACTER). Where the reader now converts
such characters to upper case it should instead call the function
that is the value of READTABLE-CHARACTER-TRANSLATION for the current
readtable. (See CLtL, page 337, step 8, point 1.)
COPY-READTABLE copies the setting of READTABLE-CHARACTER-TRANSLATION.
The value for the standard readtable is CHAR-UPCASE.
The READTABLE-CHARACTER-TRANSLATION of a readtable also has
significance when printing. The reader recognizes certain functions
which control the reader's interpretation of case and alters its
behavior accordingly. This behavior is given by the following
correspondence between functions and the keywords described above.
[This is just to avoid repeating a lot of text.]
function keyword
CHAR-UPCASE :UPCASE
CHAR-DOWNCASE :DOWNCASE
IDENTITY :PRESERVE
CHAR-INVERT-CASE :INVERT
The function can be given either as a symbol or as one of the values
#'CHAR-UPCASE, #'CHAR-DOWNCASE, #'IDENTITY, #'CHAR-INVERT-CASE.
If the READTABLE-CHARACTER-TRANSLATION is not one of the functions
listed above, letters are always printed in their own case (in
particular, *PRINT-CASE* has no effect), and all characters in
symbol names are escaped if *PRINT-ESCAPE* is true.
Define a new function CHAR-INVERT-CASE of type (FUNCTION (CHARACTER)
CHARACTER) analogous to CHAR-UPCASE and CHAR-DOWNCASE. It attempts
to convert its argument to upper-case if the argument is lower-case
and to lower-case if the argument is upper-case.
Rationale:
There are a number of different ways to achieve case-sensitivity.
These proposals are fairly simple but provide all of the
functionality that one could reasonably expect.
By using a property of the readtable, we avoid introducing a new
special variable. Any code that wishes to control all of the
reader's parameters already takes *READTABLE* into account. A new
special variable would require such code to change.
:DOWNCASE is included for symmetry with :UPCASE. :INVERT is
included so that case conventions could be used in Common Lisp code
without requiring that the names symbols in the "LISP" package be
written in upper case. (Opinions vary as to whether is is advisable
to use such conventions, but this proposal leaves that choice to the
user.)
In order to avoid complex interactions between the case setting of
the readtable and *PRINT-CASE*, this proposal specifies a
significance for *PRINT-CASE* only when the case setting is :UPCASE
or :DOWNCASE. The meaning of *PRINT-CASE* when the readtable
setting is :DOWNCASE was chosen for its simplicity and for symmetry
with :UPCASE while still being useful.
Test Case:
;; keyword version
(let ((rt (copy-readtable nil)))
(mapcar
#'(lambda (case)
(setf (readtable-case rt) case)
(read-from-string "Zebra"))
'(:upcase :downcase :preserve :invert)))
=> (ZEBRA |zebra| |Zebra| |zEBRA|) ;as printed with the standard
;readtable and *print-case* :upcase
Current Practice:
While there may not be any current implementation that supports
exactly this proposal, several implementations provide some means
for changing case sensitivity.
Franz Inc's ExCL has a function, EXCL:SET-CASE-MODE, that sets both
the "preferred case" (the case of characters in the print names of
standard symbols such as CAR) and whether or not the reader is case-
sensitive.
In Symbolics Common Lisp, the function SET-CHARACTER-TRANSLATION
can be used to make the translation of a letter be that same letter,
thus achieving case-sensitivity.
Xerox Medley has a function for setting a readtable flag that
determines case sensitivity.
Cost to Implementors:
Fairly small. The reader will be slightly slower and readtables
will be slightly more complex.
Cost to Users:
Slight. Programmers must already take into account the possibility
that *READTABLE* will be a non-standard readtable. Case-sensitivity
is no worse than character macros in this respect.
Cost of Non-Adoption:
Applications that want to read mixed-case expressions will not
be able to use the Common Lisp reader to do so (except, perhaps,
by tortuous use of read macros).
Programming styles that rely on case distinctions (without escape
characters) will be effectively impossible in Common Lisp.
Benefits:
Applications will be able to read mixed-case expressions.
Programmers will be able to make use of case distinctions.
Aesthetics:
For the proposals:
The language will have greater symmetry, because it will be
possible to control the treatment of case on both input and output
instead of only on output (as is now the case).
The language will look less old-fashioned.
Against the proposals:
It is, perhaps, inconsistent to control case-sensitivity by a
readtable operation when other aspects of the reader, such as the
input base and the default float format (not to mention the
package), are controlled by special variables. However, it can be
argued that character-level syntax is determined chiefly by the
readtable. Case-sensitivity can be seen as analogous to character
macros in this respect.
Keywords vs function
The keyword proposal is somewhat simpler and, by being less
powerful, avoids suggesting the possibility of more general
character translation (for every charcater, say, rather than
just for unescaped constituents).
The function proposal is perhaps more elegant.
Discussion:
Dalton supports both proposals but slightly prefers READTABLE-KEYWORDS.
Version 1 of the proposal suggested a new global variable rather
than a property of the readtable. Pitman was strongly opposed to
that proposal and gave convincing arguments that it should be
dropped. Gray suggested that the readtable property should be a
function.
It has been remarked that :INVERT produces somewhat strange
results. For example, Zebra reads as zEBRA. It was suggested
that inversion should happen only if the entire token was single-
case.
However, READ has to take escape characters into account (so that,
for example, |zebra| always reads as zebra), and then it is
difficult to know what rules to apply to the entire token.
Moreover, the description of READ in CLtL does not provide a
convenient place to insert processing of that sort (by the time
the full token is considered, the escape characters have been
forgotten).
∂16-Jun-89 1329 CL-Cleanup-mailer Issue: SEQUENCE-TYPE-LENGTH (version 1)
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Jun 89 13:29:06 PDT
Received: from STONY-BROOK.SCRC.SYMBOLICS.COM by argus.Stanford.EDU with TCP; Fri, 16 Jun 89 13:14:15 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 612167; 16 Jun 89 16:30:13 EDT
Date: Fri, 16 Jun 89 16:30 EDT
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Subject: Issue: SEQUENCE-TYPE-LENGTH (version 1)
Coercing sequences to vectors of different sizes
To: CL-Cleanup@sail.stanford.edu
References: <19890605191434.7.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Message-Id: <19890616203028.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
I hate to bring up a new issue so late, but maybe this one can be addressed
very quickly, or maybe somebody on the CL-Cleanup list will tell me that it
has already been addressed and I just overlooked it, which would be ideal
as far as I am concerned.
Issue: SEQUENCE-TYPE-LENGTH
References: CLtL p.51, p.249, p.260
CONCATENATE, COERCE, MAKE-SEQUENCE, MAP, MERGE
Category: CLARIFICATION
Edit history: 16-Jun-89, version 1, by Moon
Problem description:
In several functions that take a type specifier as an argument and create
a sequence of the specified type, it isn't clear what happens if the type
specifier has an explicit length that doesn't match the length implied by
the other arguments.
Proposal (SEQUENCE-TYPE-LENGTH:MUST-MATCH):
COERCE should signal an error if the new sequence type specifies the
number of elements and the old sequence has a different length.
MAKE-SEQUENCE should signal an error if the sequence type specifies the
number of elements and the size argument is different.
CONCATENATE should signal an error if the sequence type specifies the
number of elements and the sum of the argument lengths is different.
MAP should signal an error if the sequence type specifies the number of
elements and the minimum of the argument lengths is different.
MERGE should signal an error if the sequence type specifies the number of
elements and the sum of the lengths of the two sequence arguments is
different.
Examples:
;; All of the following forms should signal an error
(coerce '(a b c) '(vector * 4))
(coerce #(a b c) '(vector * 4))
(coerce '(a b c) '(vector * 2))
(coerce #(a b c) '(vector * 2))
(coerce "foo" '(string 2))
(coerce #(#\a #\b #\c) '(string 2))
(coerce '(0 1) '(simple-bit-vector 3))
(make-sequence '(vector * 2) 3)
(make-sequence '(vector * 4) 3)
(concatenate '(vector * 2) "a" "bc")
(map '(vector * 4) #'cons "abc" "de")
(merge '(vector * 4) '(1 5) '(2 4 6) #'<)
Rationale:
If CLtL hadn't overlooked this situation, it's likely that it would have
said it "is an error". The best translation of that to ANSI CL error
terminology seemed to be "should signal". There doesn't seem to be any
reason to require signalling this error even in unsafe code. There
doesn't seem to be any reason to define this situation to do something
other than signalling an error, such as ignoring the length in the
type specifier or forcing the sequence to have the correct length by
truncating or extending it with elements of implementation-dependent
value.
Current practice:
Symbolics Genera 7.2 and 7.4 usually ignore the length in the type
specifier in the above situations, but sometimes signal an error.
The type of error signalled is sometimes somewhat random.
Other implementations were not surveyed.
Cost to Implementors:
This does not seem like difficult checking to add. I have not examined
the code in any implementation to try to evaluate what it would cost.
Cost to Users:
None.
Cost of non-adoption:
Aesthetic.
Performance impact:
Probably small, just have to keep track of the length when dealing
with sequence type specifiers in safe code. I have not attempted to
evaluate the exact impact.
Benefits:
Less ambiguity in the language specification. Less deviation among
implementations, hence fewer porting problems.
Esthetics:
Since the length field is present in sequence type specifiers, it
seems unesthetic to ignore it, and even more unesthetic not to say
what is done with it.
Discussion:
Moon doesn't know what error condition is appropriate. TYPE-ERROR
doesn't seem quite appropriate here. One idea is not to say, just let it
be any subtype of ERROR. Another idea is to produce the result object
and then signal a TYPE-ERROR that this object doesn't match the
type-specifier for the result type.
∂16-Jun-89 1335 CL-Cleanup-mailer Issue: SEQUENCE-TYPE-LENGTH (version 1)
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Jun 89 13:34:22 PDT
Received: from STONY-BROOK.SCRC.SYMBOLICS.COM by argus.Stanford.EDU with TCP; Fri, 16 Jun 89 13:19:11 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 612181; 16 Jun 89 16:35:05 EDT
Date: Fri, 16 Jun 89 16:35 EDT
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Subject: Issue: SEQUENCE-TYPE-LENGTH (version 1)
Coercing sequences to vectors of different sizes
To: CL-Cleanup@sail.stanford.edu
References: <19890605191434.7.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Supersedes: <19890616203028.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comments: The first transmission forgot to include part of the discussion.
Sorry about that.
Message-Id: <19890616203524.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
I hate to bring up a new issue so late, but maybe this one can be addressed
very quickly, or maybe somebody on the CL-Cleanup list will tell me that it
has already been addressed and I just overlooked it, which would be ideal
as far as I am concerned.
Issue: SEQUENCE-TYPE-LENGTH
References: CLtL p.51, p.249, p.260, p.252, p.354
CONCATENATE, COERCE, MAKE-SEQUENCE, MAP, MERGE
Category: CLARIFICATION
Edit history: 16-Jun-89, version 1, by Moon
Problem description:
In several functions that take a type specifier as an argument and create
a sequence of the specified type, it isn't clear what happens if the type
specifier has an explicit length that doesn't match the length implied by
the other arguments.
Proposal (SEQUENCE-TYPE-LENGTH:MUST-MATCH):
COERCE should signal an error if the new sequence type specifies the
number of elements and the old sequence has a different length.
MAKE-SEQUENCE should signal an error if the sequence type specifies the
number of elements and the size argument is different.
CONCATENATE should signal an error if the sequence type specifies the
number of elements and the sum of the argument lengths is different.
MAP should signal an error if the sequence type specifies the number of
elements and the minimum of the argument lengths is different.
MERGE should signal an error if the sequence type specifies the number of
elements and the sum of the lengths of the two sequence arguments is
different.
Examples:
;; All of the following forms should signal an error
(coerce '(a b c) '(vector * 4))
(coerce #(a b c) '(vector * 4))
(coerce '(a b c) '(vector * 2))
(coerce #(a b c) '(vector * 2))
(coerce "foo" '(string 2))
(coerce #(#\a #\b #\c) '(string 2))
(coerce '(0 1) '(simple-bit-vector 3))
(make-sequence '(vector * 2) 3)
(make-sequence '(vector * 4) 3)
(concatenate '(vector * 2) "a" "bc")
(map '(vector * 4) #'cons "abc" "de")
(merge '(vector * 4) '(1 5) '(2 4 6) #'<)
Rationale:
If CLtL hadn't overlooked this situation, it's likely that it would have
said it "is an error". The best translation of that to ANSI CL error
terminology seemed to be "should signal". There doesn't seem to be any
reason to require signalling this error even in unsafe code. There
doesn't seem to be any reason to define this situation to do something
other than signalling an error, such as ignoring the length in the
type specifier or forcing the sequence to have the correct length by
truncating or extending it with elements of implementation-dependent
value.
Current practice:
Symbolics Genera 7.2 and 7.4 usually ignore the length in the type
specifier in the above situations, but sometimes signal an error.
The type of error signalled is sometimes somewhat random.
Other implementations were not surveyed.
Cost to Implementors:
This does not seem like difficult checking to add. I have not examined
the code in any implementation to try to evaluate what it would cost.
Cost to Users:
None.
Cost of non-adoption:
Aesthetic.
Performance impact:
Probably small, just have to keep track of the length when dealing
with sequence type specifiers in safe code. I have not attempted to
evaluate the exact impact.
Benefits:
Less ambiguity in the language specification. Less deviation among
implementations, hence fewer porting problems.
Esthetics:
Since the length field is present in sequence type specifiers, it
seems unesthetic to ignore it, and even more unesthetic not to say
what is done with it.
Discussion:
Moon doesn't know what error condition is appropriate. TYPE-ERROR
doesn't seem quite appropriate here. One idea is not to say, just let it
be any subtype of ERROR. Another idea is to produce the result object
and then signal a TYPE-ERROR that this object doesn't match the
type-specifier for the result type.
Cassels points out that two similar operations are defined in CLtL to be
inconsistent with each other:
(replace (make-array 4) #(1 2 3)) just picks the shortest length, and
"the extra elements near the end of the longer subsequence are not
involved in the operation" so the result is #(1 2 3 NIL)
#4(1 2 3) duplicates the last element, so it's like #(1 2 3 3)
#2(1 2 3) "is an error".
∂16-Jun-89 1617 CL-Cleanup-mailer Issue: READ-CASE-SENSITIVITY (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 16 Jun 89 16:17:11 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 612361; 16 Jun 89 19:19:03 EDT
Date: Fri, 16 Jun 89 19:19 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: READ-CASE-SENSITIVITY (Version 3)
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <19558.8906161835@aiai.ed.ac.uk>
Message-ID: <19890616231919.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 16 Jun 89 19:35:44 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
I am not going to be able to come to the meeting but would
still like to see this issue considered. I wasn't present
for the discussion at the last meeting, but my understanding
is that the committee wanted to see the issue again with
only a single proposal.
Yes, a single proposal is much better. I'd very much like to see
this considered, and a single proposal will make that much easier.
Unfortunately, I don't know which
proposal (keyword or function) most people prefer.
I don't either, but I know that at Symbolics we strongly prefer
the keyword proposal. Since the discussion section says you prefer
the keyword proposal, perhaps as the author you could use your
discretion to opt for that proposal and send out a version 4
omitting the function proposal and the discussion of the relative
merits of the two proposals.
It has also been remarked that :INVERT is somewhat strange in that it
would have Zebra read as zEBRA; and it was suggested that inversion
should happen only if the entire name were single-case.
Unfortunately, the processing has to happen a character at a time,
because READ has to do it only for characters that are not escaped.
I don't believe that the conclusion follows from the premise.
For example, |zebra| should always read as zebra.
However, READ has to take escape characters into account (so that,
for example, |zebra| always reads as zebra), and then it is
difficult to know what rules to apply to the entire token.
Moreover, the description of READ in CLtL does not provide a
convenient place to insert processing of that sort (by the time
the full token is considered, the escape characters have been
forgotten).
The parenthesized clause is clearly false, since escapedness is
remembered for purposes of package syntax and number/potential number
syntax. I believe it would be possible to make :INVERT apply only if
the entire name is single-case. It remains true that we have to decide
whether "the entire name" includes escaped characters or not (in either
case, only the unescaped characters would be inverted). The Genera
reader does case processing character at a time, as you outlined, but
could very easily implement :INVERT based on either the escaped
characters or all the characters, so that's an existence proof (hint:
one state in its finite state machine would be split into four states,
depending on whether any letters have been seen so far and on whether
they are all upper case, all lower case, or mixed case). Unless someone
cleverer than me comes up with an algorithm, it would be necessary to
retain the symbol-name in both inverted and uninverted form until
the entire token has been parsed, but the cost of that is negligible.
I think it would be best to base the decision on only the unescaped
characters. That just seems more consistent with the rest of the reader.
Can you / will you write a version 4 that contains only the keywords
proposal and that specifies :INVERT to invert case only when all the
unescaped letters are in a single case?
∂16-Jun-89 2049 CL-Cleanup-mailer issue DYNAMIC-EXTENT-FUNCTION, version 2
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 16 Jun 89 20:49:45 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 612459; 16 Jun 89 23:51:36 EDT
Date: Fri, 16 Jun 89 23:52 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue DYNAMIC-EXTENT-FUNCTION, version 2
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8906111926.AA20929@defun.utah.edu>
Message-ID: <19890617035202.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
This is okay.
∂16-Jun-89 2122 CL-Cleanup-mailer Issue: PATHNAME-SYSTEM-TYPE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 16 Jun 89 21:22:32 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 612464; 17 Jun 89 00:24:32 EDT
Date: Sat, 17 Jun 89 00:24 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SYSTEM-TYPE (Version 1)
To: Kim Barrett <IIM@ECLA.USC.EDU>
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19890613222547.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890617042459.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 13 Jun 89 18:25 EDT
From: Kim Barrett <IIM@ECLA.USC.EDU>
:ITS ? ;I think some of these are still around.
:MACINTOSH ?
:TENEX ? ;Do any still exist? I briefly used BBN LISP on one.
Any others people want to add?
There are at least four running ITS systems in daily use around
the world, and may be more. But there are fewer than ten. Just
thought you'd like to know.
ITS and TENEX are listed in the Internet RFC 1010 table of system
names referenced by the proposal. MACINTOSH is not. Since I
couldn't find any alternate spelling in the RFC, I think this is
just an omission and MACINTOSH would be the preferred name. I'll
add it to the list in the proposal. I imagine Macintosh was
omitted because Apple has been a bit slow about getting into the
Internet community (in addition to doing their own proprietary
networking).
∂17-Jun-89 0851 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 3)
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 17 Jun 89 08:51:12 PDT
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP
id aa05325; 17 Jun 89 16:43 BST
Date: Sat, 17 Jun 89 16:50:44 BST
Message-Id: <22133.8906171550@aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 3)
To: "David A. Moon" <Moon@stony-brook.scrc.symbolics.com>
In-Reply-To: David A. Moon's message of Fri, 16 Jun 89 19:19 EDT
Cc: cl-cleanup@sail.stanford.edu
> Unfortunately, I don't know which
> proposal (keyword or function) most people prefer.
>
> I don't either, but I know that at Symbolics we strongly prefer
> the keyword proposal. Since the discussion section says you prefer
> the keyword proposal, perhaps as the author you could use your
> discretion to opt for that proposal and send out a version 4
> omitting the function proposal and the discussion of the relative
> merits of the two proposals.
OK, I'll do that unless people start speaking up for the function
proposal.
> It has also been remarked that :INVERT is somewhat strange in that it
> would have Zebra read as zEBRA; and it was suggested that inversion
> should happen only if the entire name were single-case.
>
> Unfortunately, the processing has to happen a character at a time,
> because READ has to do it only for characters that are not escaped.
>
> I don't believe that the conclusion follows from the premise.
You're probably right, since it looks like you have a better
understanding of this that I do.
What I wanted to do was just to change point 1 of step 8 on page 337
of CLtL, which is where unescaped constituents are converted to upper
case. At that point, characters are being considered one at a time.
If :INVERT's going to work on entire extended tokens, it looks like it
requires a more complicated change to the specification of READ.
> For example, |zebra| should always read as zebra.
> However, READ has to take escape characters into account (so that,
> for example, |zebra| always reads as zebra), and then it is
> difficult to know what rules to apply to the entire token.
> Moreover, the description of READ in CLtL does not provide a
> convenient place to insert processing of that sort (by the time
> the full token is considered, the escape characters have been
> forgotten).
>
> The parenthesized clause is clearly false, since escapedness is
> remembered for purposes of package syntax and number/potential number
> syntax.
How it seemed to me was that escapedness was remembered only to the
extent that escaped characters were considered to have only the
attribute alphabetic. But maybe that's enough, since letters
normally have the attribute alphadigit. But then, strictly
speaking, that attribute depends on the setting of *READ-BASE*.
> I believe it would be possible to make :INVERT apply only if
> the entire name is single-case. It remains true that we have to decide
> whether "the entire name" includes escaped characters or not (in either
> case, only the unescaped characters would be inverted). The Genera
> reader does case processing character at a time, as you outlined, but
> could very easily implement :INVERT based on either the escaped
> characters or all the characters, so that's an existence proof (hint:
> one state in its finite state machine would be split into four states,
> depending on whether any letters have been seen so far and on whether
> they are all upper case, all lower case, or mixed case). Unless someone
> cleverer than me comes up with an algorithm, it would be necessary to
> retain the symbol-name in both inverted and uninverted form until
> the entire token has been parsed, but the cost of that is negligible.
> I think it would be best to base the decision on only the unescaped
> characters. That just seems more consistent with the rest of the
> reader.
The CLtL model seems to be that the characters are accumulated then
processed as a "extended token". So the rule would be something like
this:
If the read case of the current readtable is :INVERT and
if if all of the unescaped letters in the extended token are
of the same case, those letters are converted to the opposite
case.
I'm a bit worried about the use of "unescaped" at this point,
since the other parts of the processing of extended token depend
only on attributes such as alphabetic or digit.
I'm also a bit worried about things like this:
\abc reads as aBC, but prints as Abc
> Can you / will you write a version 4 that contains only the keywords
> proposal and that specifies :INVERT to invert case only when all the
> unescaped letters are in a single case?
Yes to at least the first. I'd like to have some more feedback on the
second.
-- Jeff
∂18-Jun-89 1307 CL-Cleanup-mailer Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 18 Jun 89 13:07:01 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA22209; Sun, 18 Jun 89 14:07:25 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA26018; Sun, 18 Jun 89 14:07:18 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906182007.AA26018@defun.utah.edu>
Date: Sun, 18 Jun 89 14:07:17 MDT
Subject: Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 13 Jun 89 19:17 EDT
[removed x3j13, added cl-cleanup to distribution]
> If the array returned by ADJUST-ARRAY is not EQ to its
> first argument, the consequences of any reference to the original array
> are undefined.
I'm not sure I understand the motivation for this restriction. I'm
guessing that you want to permit the storage used by the original
array to be re-used. This is OK, however, I think prohibiting
references to the original array is going overboard -- you probably
really want to only restrict references to its contents via AREF.
For example, the rationale section says you should do
(setq x (adjust-array x ...))
Just after ADJUST-ARRAY returns, but before the SETQ happens, X
still contains a reference to the original array, and hence this example
is in error.
-Sandra
-------
∂19-Jun-89 0930 CL-Cleanup-mailer Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 19 Jun 89 09:30:44 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 612975; 19 Jun 89 12:30:58 EDT
Date: Mon, 19 Jun 89 12:31 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8906182007.AA26018@defun.utah.edu>
Message-ID: <19890619163136.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun, 18 Jun 89 14:07:17 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
[removed x3j13, added cl-cleanup to distribution]
> If the array returned by ADJUST-ARRAY is not EQ to its
> first argument, the consequences of any reference to the original array
> are undefined.
I'm not sure I understand the motivation for this restriction. I'm
guessing that you want to permit the storage used by the original
array to be re-used.
I imagine that was the intent.
This is OK, however, I think prohibiting
references to the original array is going overboard -- you probably
really want to only restrict references to its contents via AREF.
For example, the rationale section says you should do
(setq x (adjust-array x ...))
Just after ADJUST-ARRAY returns, but before the SETQ happens, X
still contains a reference to the original array, and hence this example
is in error.
I see, the word "reference" is ambiguous. It could mean performing an
operation on the array, or it could mean having a reference in the garbage
collector sense. How about if "any reference to" were amended to read
"any operation on"?
∂19-Jun-89 1007 CL-Cleanup-mailer mail lossage (and Issue: READ-CASE-SENSITIVITY (Version 3))
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 19 Jun 89 10:06:52 PDT
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP
id aa07405; 19 Jun 89 17:45 BST
Date: Mon, 19 Jun 89 17:53:54 BST
Message-Id: <877.8906191653@aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: mail lossage (and Issue: READ-CASE-SENSITIVITY (Version 3))
To: "David A. Moon" <Moon@stony-brook.scrc.symbolics.com>
In-Reply-To: David A. Moon's message of Fri, 16 Jun 89 19:19 EDT
Cc: cl-cleanup@sail.stanford.edu
I did get this
> Date: Fri, 16 Jun 89 19:35:44 BST
> From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
>
> I am not going to be able to come to the meeting but would
> still like to see this issue considered. I wasn't present
> for the discussion at the last meeting, but my understanding
> is that the committee wanted to see the issue again with
> only a single proposal.
>
> Yes, a single proposal is much better. I'd very much like to see
> this considered, and a single proposal will make that much easier.
>
> Unfortunately, I don't know which
> proposal (keyword or function) most people prefer.
>
> I don't either, but I know that at Symbolics we strongly prefer
> the keyword proposal. Since the discussion section says you prefer
> the keyword proposal, perhaps as the author you could use your
> discretion to opt for that proposal and send out a version 4
> omitting the function proposal and the discussion of the relative
> merits of the two proposals.
> [etc.]
If anyone sent me mail this weekend (or mail that may have arrived
before this afternoon (UK time), I probably didn't get it, because
the machine that receives my CL mail was very broken.
-- Jeff
∂19-Jun-89 1020 CL-Cleanup-mailer Issue: MAP-INTO (version 2)
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 19 Jun 89 10:20:25 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Mon, 19 Jun 89 13:21:02 EDT
Date: Mon, 19 Jun 89 13:19 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: MAP-INTO (version 2)
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <19890619161633.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <19890619171920.3.BARMAR@OCCAM.THINK.COM>
Date: Mon, 19 Jun 89 12:16 EDT
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
The function must take at least as many arguments as there are
sequences provided, and at least one sequence must be provided.
I suggest relaxing this, to allow zero argument sequences. The length of
the result-sequence would control the number of times the function is
called. This would permit something like
(map-into my-sequence #'(lambda () (random 1.0)))
to fill a sequence with random numbers.
This appears to be what Genera does.
The arguments result-sequence and each element of sequences can each be
either a list or a vector (one-dimensional array). Note that nil is
considered to be a sequence, of length zero. If result-sequence and
each element of sequences are not all the same length, the iteration
terminates when the shortest sequence is exhausted.
I assume that the result-sequence is included when determining the
shortest sequence. If result-sequence is a vector with a fill pointer,
or an adjustable vector, how does this affect things? Intuitively, the
following things seem reasonable:
1) The result-sequence's fill pointer could be set to the number of
elements modified (i.e. the minimum of the sequences' lengths).
2) The result-sequence should be filled as if its fill pointer were
initially 0, and each result is then VECTOR-PUSHed onto the
vector. This implies (1).
3) When minimizing the sequence lengths, (array-dimension
result-sequence 0) should be used, rather than (length result-sequence),
so that the previous value of the result sequence's fill pointer does
not cause the iteration to terminate prematurely. This also implies
that the VECTOR-PUSH will never try to go beyond the size of the vector.
In the case where no argument sequences are provided, it might be
reasonable to use (length result-sequence), but I think it would be
better to maintain consistency. Fill pointers are generally used to
indicate which elements a reader should look at, not to restrict filling
in (for instance, make-array :initial-element initializes ALL the
elements, not just up to the fill pointer).
Genera appears to use (length result-sequence) all the time.
barmar
∂19-Jun-89 1021 CL-Cleanup-mailer Re: Issue: DATA-IO (version 7)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 19 Jun 89 10:21:19 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA12676; Mon, 19 Jun 89 11:21:40 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA26643; Mon, 19 Jun 89 11:21:38 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906191721.AA26643@defun.utah.edu>
Date: Mon, 19 Jun 89 11:21:36 MDT
Subject: Re: Issue: DATA-IO (version 7)
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: CL-Cleanup@sail.stanford.edu, Mon, 19 Jun 89 11:47 EDT
I have two remarks on this proposal.
In section 1a, it says:
If *PRINT-READABLY* is true, then printing any object produces a
printed representation that the reader will accept.
This seems underspecified to me. At least for implementation-defined
print methods, it ought to be stated what the relationship is between
the object that is printed and the object that is read in again is.
Can we use "similar as constants" here?
In sections 1c, 1d, and 1e, it uses "might" to describe the
interaction between *PRINT-READABLY*, *PRINT-LEVEL*, *PRINT-LENGTH*,
and *PRINT-ESCAPE*. Is there some reason that we can't tie this behavior
down more definitely?
-Sandra
-------
∂19-Jun-89 1032 CL-Cleanup-mailer Issue: BIT-ARRAY-FUNCTIONS (version 6)
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 19 Jun 89 10:32:37 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Mon, 19 Jun 89 13:33:13 EDT
Date: Mon, 19 Jun 89 13:31 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: BIT-ARRAY-FUNCTIONS (version 6)
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <19890619161334.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <19890619173133.4.BARMAR@OCCAM.THINK.COM>
I'd like to suggest an additional change, which seems to be consistent
with the attitude about use of bit vectors expressed in the proposal.
The BIT and SBIT functions should return 0 if asked to access outside
the bit array. This would maintain the tautology
(bit (bit-XXX v1 v2) n) == (logXXX (bit v1 n) (bit v2 n))
If slowing down these functions (they'd be the only array accessors
REQUIRED to check the dimensions) is considered unacceptable, then a new
accessor should be added.
barmar
∂19-Jun-89 1046 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 3)
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 19 Jun 89 10:46:28 PDT
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP
id ab07945; 19 Jun 89 18:32 BST
Date: Mon, 19 Jun 89 18:40:14 BST
Message-Id: <1097.8906191740@aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 3)
To: "David A. Moon" <Moon@stony-brook.scrc.symbolics.com>
In-Reply-To: David A. Moon's message of Fri, 16 Jun 89 19:19 EDT
Cc: cl-cleanup@sail.stanford.edu
> Unfortunately, I don't know which
> proposal (keyword or function) most people prefer.
>
> I don't either, but I know that at Symbolics we strongly prefer
> the keyword proposal. Since the discussion section says you prefer
> the keyword proposal, perhaps as the author you could use your
> discretion to opt for that proposal and send out a version 4
> omitting the function proposal and the discussion of the relative
> merits of the two proposals.
OK, I'll do that unless people start speaking up for the function
proposal.
> It has also been remarked that :INVERT is somewhat strange in that it
> would have Zebra read as zEBRA; and it was suggested that inversion
> should happen only if the entire name were single-case.
>
> Unfortunately, the processing has to happen a character at a time,
> because READ has to do it only for characters that are not escaped.
>
> I don't believe that the conclusion follows from the premise.
You're probably right, since it looks like you have a better
understanding of this that I do.
What I wanted to do was just to change point 1 of step 8 on page 337
of CLtL, which is where unescaped constituents are converted to upper
case. At that point, characters are being considered one at a time.
If :INVERT's going to work on entire extended tokens, it looks like it
requires a more complicated change to the specification of READ.
> For example, |zebra| should always read as zebra.
> However, READ has to take escape characters into account (so that,
> for example, |zebra| always reads as zebra), and then it is
> difficult to know what rules to apply to the entire token.
> Moreover, the description of READ in CLtL does not provide a
> convenient place to insert processing of that sort (by the time
> the full token is considered, the escape characters have been
> forgotten).
>
> The parenthesized clause is clearly false, since escapedness is
> remembered for purposes of package syntax and number/potential number
> syntax.
How it seemed to me was that escapedness was remembered only to the
extent that escaped characters were considered to have only the
attribute alphabetic. But maybe that's enough, since letters
normally have the attribute alphadigit. But then, strictly
speaking, that attribute depends on the setting of *READ-BASE*.
> I believe it would be possible to make :INVERT apply only if
> the entire name is single-case. It remains true that we have to decide
> whether "the entire name" includes escaped characters or not (in either
> case, only the unescaped characters would be inverted). The Genera
> reader does case processing character at a time, as you outlined, but
> could very easily implement :INVERT based on either the escaped
> characters or all the characters, so that's an existence proof (hint:
> one state in its finite state machine would be split into four states,
> depending on whether any letters have been seen so far and on whether
> they are all upper case, all lower case, or mixed case). Unless someone
> cleverer than me comes up with an algorithm, it would be necessary to
> retain the symbol-name in both inverted and uninverted form until
> the entire token has been parsed, but the cost of that is negligible.
> I think it would be best to base the decision on only the unescaped
> characters. That just seems more consistent with the rest of the
> reader.
The CLtL model seems to be that the characters are accumulated then
processed as a "extended token". So the rule would be something like
this:
If the read case of the current readtable is :INVERT and
if if all of the unescaped letters in the extended token are
of the same case, those letters are converted to the opposite
case.
I'm a bit worried about the use of "unescaped" at this point,
since the other parts of the processing of extended token depend
only on attributes such as alphabetic or digit.
I'm also a bit worried about things like this:
\abc reads as aBC, but prints as Abc
> Can you / will you write a version 4 that contains only the keywords
> proposal and that specifies :INVERT to invert case only when all the
> unescaped letters are in a single case?
Yes to at least the first. I'd like to have some more feedback on the
second.
-- Jeff
∂19-Jun-89 1047 CL-Cleanup-mailer Issue: BIT-ARRAY-FUNCTIONS (version 6)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 19 Jun 89 10:47:50 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 613102; 19 Jun 89 13:44:00 EDT
Date: Mon, 19 Jun 89 13:44 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: BIT-ARRAY-FUNCTIONS (version 6)
To: Barry Margolin <barmar@Think.COM>
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <19890619173133.4.BARMAR@OCCAM.THINK.COM>
Message-ID: <19890619174433.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 19 Jun 89 13:31 EDT
From: Barry Margolin <barmar@Think.COM>
I'd like to suggest an additional change, which seems to be consistent
with the attitude about use of bit vectors expressed in the proposal.
The BIT and SBIT functions should return 0 if asked to access outside
the bit array. This would maintain the tautology
(bit (bit-XXX v1 v2) n) == (logXXX (bit v1 n) (bit v2 n))
If slowing down these functions (they'd be the only array accessors
REQUIRED to check the dimensions) is considered unacceptable, then a new
accessor should be added.
I don't like this idea.
If upon reflection you still like it, could you prepare an amendment
to bring up at the meeting next week?
∂19-Jun-89 1109 CL-Cleanup-mailer Re: Issue: DATA-IO (version 7)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 19 Jun 89 11:09:01 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 613141; 19 Jun 89 14:07:28 EDT
Date: Mon, 19 Jun 89 14:08 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: DATA-IO (version 7)
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <8906191721.AA26643@defun.utah.edu>
Message-ID: <19890619180800.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 19 Jun 89 11:21:36 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
I have two remarks on this proposal.
In section 1a, it says:
If *PRINT-READABLY* is true, then printing any object produces a
printed representation that the reader will accept.
This seems underspecified to me. At least for implementation-defined
print methods, it ought to be stated what the relationship is between
the object that is printed and the object that is read in again is.
I had assumed this was already specified for PRINT, independent of
*PRINT-READABLY*. CLtL p.333 mentions the issue but its off-handed
comment about "obscure technical exceptions" does not make me feel secure.
"What the Print Function Produces" (CLtL p.365) says some fairly specific
things.
Can we use "similar as constants" here?
Probably. I'll have to go re-read its definition before I can so for
sure. I'll see if I can find the time to prepare an amendment to bring
to the meeting (although if someone else volunteers to do it, I am
unlikely to complain!)
In sections 1c, 1d, and 1e, it uses "might" to describe the
interaction between *PRINT-READABLY*, *PRINT-LEVEL*, *PRINT-LENGTH*,
and *PRINT-ESCAPE*. Is there some reason that we can't tie this behavior
down more definitely?
Only that I didn't think it was important and didn't want to spend the time
to try to find something that made sense and was consistent with all forms
of current practice (if possible). I think an amendment would be good
if you have definite behavior you'd like to propose. I'll see if I can
find the time to think about this, but I can't promise anything.
∂19-Jun-89 1255 CL-Cleanup-mailer Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 19 Jun 89 12:55:31 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA18852; Mon, 19 Jun 89 13:55:54 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA26744; Mon, 19 Jun 89 13:55:52 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906191955.AA26744@defun.utah.edu>
Date: Mon, 19 Jun 89 13:55:50 MDT
Subject: Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Mon, 19 Jun 89 12:31 EDT
> I see, the word "reference" is ambiguous. It could mean performing an
> operation on the array, or it could mean having a reference in the garbage
> collector sense. How about if "any reference to" were amended to read
> "any operation on"?
I suppose that would be OK, as would something like "any attempt to
access". However, I'm still a little apprehensive here that there
might still be unexpected problems, like if the user is stepping
through the code with the debugger and tries to examine the values of
local variables. The real problem is that this operation can
potentially invalidate the original object by freeing some of its
storage, or otherwise stuffing garbage into it. I don't think that
any other destructive operations are permitted to do this, and it does
seem to violate the principle that Lisp objects have indefinite
extent. I wonder if it's worth adding such ugliness to the language
just for the sake of an efficiency hack. I would feel more
comfortable if this sentence were removed entirely and ADJUST-ARRAY
not permitted to bash the original array unless it returns an object
that is EQ to it.
Incidentally, I have discussed this issue more generally with others
here. We like the idea of making ADJUST-ARRAY work on all arrays, but
we would like to see ADJUSTABLE-ARRAY-P removed from the language
altogether. We don't think that the way this proposal redefines it is
particularly useful.
-Sandra
-------
∂19-Jun-89 1313 CL-Cleanup-mailer re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
To: sandra%defun@CS.UTAH.EDU
CC: cl-cleanup@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
[In reply to message from sandra%defun@cs.utah.edu sent Mon, 19 Jun 89 13:55:50 MDT.]
I tend to agree with Sandra: I would just as soon see the array
handed to ADJUST-ARRAY either turned into the new array or left alone,
depending on whether ADJUST-ARRAY copies.
My preference is to see ADJUSTABLE-ARRAY-P removed, but this is
based simply on elegance. I can live with either position.
-rpg-
∂19-Jun-89 1349 CL-Cleanup-mailer Re: Issue: DATA-IO (version 7)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 19 Jun 89 13:48:54 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA20131; Mon, 19 Jun 89 14:39:49 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA26781; Mon, 19 Jun 89 14:39:47 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906192039.AA26781@defun.utah.edu>
Date: Mon, 19 Jun 89 14:39:45 MDT
Subject: Re: Issue: DATA-IO (version 7)
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
CL-Cleanup@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Mon, 19 Jun 89 14:08 EDT
> I had assumed this was already specified for PRINT, independent of
> *PRINT-READABLY*. CLtL p.333 mentions the issue but its off-handed
> comment about "obscure technical exceptions" does not make me feel secure.
> "What the Print Function Produces" (CLtL p.365) says some fairly specific
> things.
Right. What I want to know is, does the addition of *PRINT-READABLY*
cause changes or additions to anything already stated in this section?
For example, if *PRINT-READABLY* is true, are arrays still required to
print using #A syntax even though it loses information about
attributes such as the element type? (For that matter, is there an
interaction between *PRINT-ARRAY* and *PRINT-READABLY*?) I question
whether this proposal is really ready to be voted on in its current
state.
> In sections 1c, 1d, and 1e, it uses "might" to describe the
> interaction between *PRINT-READABLY*, *PRINT-LEVEL*, *PRINT-LENGTH*,
> and *PRINT-ESCAPE*. Is there some reason that we can't tie this behavior
> down more definitely?
>
> Only that I didn't think it was important and didn't want to spend the time
> to try to find something that made sense and was consistent with all forms
> of current practice (if possible). I think an amendment would be good
> if you have definite behavior you'd like to propose.
I mostly just want to see one rule that is applied consistently when
*PRINT-READABLY* is true and the value of any of the other variables
is such that the object would otherwise be printed in an unreadable
manner. The two obvious choices are that either the other variable is
ignored, or that an error is signalled. The first might be slightly
easier to implement but I don't really have a strong preference one
way or the other. (Even if it's decided to leave this behavior
unspecified, I think describing it in this way instead of as a bunch
of special cases would improve the presentation.)
-Sandra
-------
∂19-Jun-89 1540 CL-Cleanup-mailer Issue: BIT-ARRAY-FUNCTIONS (version 6)
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 19 Jun 89 15:40:23 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Mon, 19 Jun 89 18:41:01 EDT
Date: Mon, 19 Jun 89 18:39 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: BIT-ARRAY-FUNCTIONS (version 6)
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <19890619174433.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <19890619223922.8.BARMAR@OCCAM.THINK.COM>
Date: Mon, 19 Jun 89 13:44 EDT
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Date: Mon, 19 Jun 89 13:31 EDT
From: Barry Margolin <barmar@Think.COM>
I'd like to suggest an additional change, which seems to be consistent
with the attitude about use of bit vectors expressed in the proposal.
The BIT and SBIT functions should return 0 if asked to access outside
the bit array. This would maintain the tautology
(bit (bit-XXX v1 v2) n) == (logXXX (bit v1 n) (bit v2 n))
If slowing down these functions (they'd be the only array accessors
REQUIRED to check the dimensions) is considered unacceptable, then a new
accessor should be added.
I don't like this idea.
Could you elaborate? Why is it that you like the idea of assuming 0
elements on the end when combining bit vectors, but not when accessing
them? Either you think of them as being infinitely padded with zeros,
or you don't.
I'm not sure I really grasp the whole motivation for this change.
Anyone who needs the kind of functionality being proposed can already
get it by using the boolean integer functions. They already provide the
infinitely-padded-with-zeroes feature. In fact, they also provide
infinitely-padded-with-ones, also, in the form of negative numbers.
barmar
∂19-Jun-89 1545 CL-Cleanup-mailer Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 19 Jun 89 15:45:05 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 613316; 19 Jun 89 17:49:54 EDT
Date: Mon, 19 Jun 89 17:50 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8906191955.AA26744@defun.utah.edu>
Message-ID: <19890619215033.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 19 Jun 89 13:55:50 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
> I see, the word "reference" is ambiguous. It could mean performing an
> operation on the array, or it could mean having a reference in the garbage
> collector sense. How about if "any reference to" were amended to read
> "any operation on"?
I suppose that would be OK, as would something like "any attempt to
access". However, I'm still a little apprehensive here that there
might still be unexpected problems, like if the user is stepping
through the code with the debugger and tries to examine the values of
local variables. The real problem is that this operation can
potentially invalidate the original object by freeing some of its
storage, or otherwise stuffing garbage into it. I don't think that
any other destructive operations are permitted to do this, and it does
seem to violate the principle that Lisp objects have indefinite
extent. I wonder if it's worth adding such ugliness to the language
just for the sake of an efficiency hack. I would feel more
comfortable if this sentence were removed entirely and ADJUST-ARRAY
not permitted to bash the original array unless it returns an object
that is EQ to it.
Reusing the storage wasn't my idea, so removing that wart is fine with me.
Incidentally, I have discussed this issue more generally with others
here. We like the idea of making ADJUST-ARRAY work on all arrays, but
we would like to see ADJUSTABLE-ARRAY-P removed from the language
altogether. We don't think that the way this proposal redefines it is
particularly useful.
I'm neutral on this. I am able to imagine applications where the
ADJUSTABLE-ARRAY-P would be useful to call before calling ADJUST-ARRAY.
It sounds like I'm elected to prepare a slightly amended version of the
proposal in a couple of days.
∂20-Jun-89 1358 CL-Cleanup-mailer Issue: SEQUENCE-TYPE-LENGTH (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 20 Jun 89 13:56:47 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 614088; 20 Jun 89 16:58:39 EDT
Date: Tue, 20 Jun 89 16:59 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SEQUENCE-TYPE-LENGTH (version 1)
Coercing sequences to vectors of different sizes
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <19890616203524.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890620205907.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
No one has commented on this yet.
How about if using a sequence type-specifier with a length or a
numeric type-specifier with a subrange (the latter in COERCE only)
was defined to be not allowed? It could be "should signal an error"
or "the consequences are unspecified".
∂20-Jun-89 1943 CL-Cleanup-mailer Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 20 Jun 89 19:43:13 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 614297; 20 Jun 89 22:45:04 EDT
Date: Tue, 20 Jun 89 22:44 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, Cl-Cleanup@SAIL.Stanford.EDU, sandra%defun@cs.utah.edu
Message-ID: <19890621024458.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
The proposal as written sounds fine to me. I would be content to vote
Yes on it as is.
Since there was a hint of future changes possible, here are a few
comments on the changes I might anticipate based on the discussion...
- I agree with Sandra that the array should not be altered unless the EQ
array is going to be returned.
- I do not want to see ADJUSTABLE-ARRAY-P removed because it provides
important functionality. Sometimes you cannot call ADJUST-ARRAY because
you don't own all the pointers and cannot do the magic SETQ and some
applications may need to be able to detect this dynamically, perhaps
going into the debugger in that case, but at least having the option to
know.
I will concede that ADJUSTABLE-ARRAY-P is now misnamed. Perhaps that's
what really makes people want to flush it. It no longer answers the
question it looks like it does -- but it does answer a useful question.
Suppose it was
:ADJUST-ACTION :COPY (or :NEW)
or :ADJUST-ACTION :IDENTITY (or :RECYCLE)
Then you would say
(MAKE-ARRAY ... :ADJUST-ACTION :COPY)
and
(ARRAY-ADJUST-ACTION foo) => :COPY
Or if you prefer booleans,
(MAKE-ARRAY ... :ADJUST-WILL-COPY T) ;or NIL
and
(ARRAY-ADJUST-WILL-COPY foo) => T ;or NIL
Note that -MIGHT-COPY could be chosen, too, if that was the preferrable sense.
I'm mostly just trying to illustrate the space of possible naming styles, not
take a stand on a particular style.
The latter case is a simple renaming. The former is more in the style
used by the OPEN function.
∂20-Jun-89 2123 CL-Cleanup-mailer re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
To: KMP@STONY-BROOK.SCRC.SYMBOLICS.COM, Moon@STONY-BROOK.SCRC.SYMBOLICS.COM
CC: Cl-Cleanup@SAIL.Stanford.EDU, sandra%defun@CS.UTAH.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
[In reply to message from KMP@STONY-BROOK.SCRC.Symbolics.COM sent Tue, 20 Jun 89 22:44 EDT.]
KMP writes:
Sometimes you cannot call ADJUST-ARRAY because
you don't own all the pointers and cannot do the magic SETQ and some
applications may need to be able to detect this dynamically, perhaps
going into the debugger in that case, but at least having the option to
know.
Seems like the smart applications writer is going to write
(make-array...:adjustable t ...)
rather than go into the debugger or something failure-like. This should
serve him well, especially if all implementations he uses implements
:ADJUST-ARRAY T by making an adjustable-array.
ADJUSTABLE-ARRAY-P is an acceptable name because it is testing whether the
array is adjustable, not whether you can invoke ADJUST-ARRAY on it. Maybe
this is the first time it had the right name. ADJUST-ARRAY, on the other
hand, might be better with a different name. Deciding that better name
is as hard as deciding what the right name for ADJUSTABLE-ARRAY-P should
have been (ABLE-TO-INVOKE-ADJUST-ARRAY-ON-P?).
-rpg-
∂20-Jun-89 2347 CL-Cleanup-mailer Rejected mail
Received: from kth.se by SAIL.Stanford.EDU with TCP; 20 Jun 89 23:47:39 PDT
Received: by kth.se (5.61+IDA/KTH/LTH/4.0)
id AAkth20229; Wed, 21 Jun 89 08:47:07 +0200
Date: Wed, 21 Jun 89 08:47:07 +0200
Message-Id: <8906210647.AAkth20229@kth.se>
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Subject: Rejected mail
Apparently-To: CL-Cleanup@sail.stanford.edu
<cl_cleanup@eva.slu.se>... 550 Host unknown (Authoritative answer from name server)
Original message follows:
=====================================================================
Received: by Forsythe.Stanford.EDU; Mon, 19 Jun 89 10:26:58 PDT
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 19 Jun 89 10:21:19
PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA12676; Mon, 19 Jun 89 11:21:40 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA26643; Mon, 19 Jun 89 11:21:38 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906191721.AA26643@defun.utah.edu>
Date: Mon, 19 Jun 89 11:21:36 MDT
Subject: Re: Issue: DATA-IO (version 7)
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: CL-Cleanup@sail.stanford.edu, Mon, 19 Jun 89 11:47 EDT
I have two remarks on this proposal.
In section 1a, it says:
If *PRINT-READABLY* is true, then printing any object produces a
printed representation that the reader will accept.
This seems underspecified to me. At least for implementation-defined
print methods, it ought to be stated what the relationship is between
the object that is printed and the object that is read in again is.
Can we use "similar as constants" here?
In sections 1c, 1d, and 1e, it uses "might" to describe the
interaction between *PRINT-READABLY*, *PRINT-LEVEL*, *PRINT-LENGTH*,
and *PRINT-ESCAPE*. Is there some reason that we can't tie this behavior
down more definitely?
-Sandra
-------
∂21-Jun-89 0703 CL-Cleanup-mailer Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 21 Jun 89 07:03:43 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA17727; Wed, 21 Jun 89 08:03:24 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA01380; Wed, 21 Jun 89 08:03:21 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906211403.AA01380@defun.utah.edu>
Date: Wed, 21 Jun 89 08:03:20 MDT
Subject: Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
To: Jon L White <jonl@lucid.com>
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@sail.stanford.edu
In-Reply-To: Jon L White <jonl@lucid.com>, Tue, 20 Jun 89 22:35:42 PDT
[Removed X3J13; added cl-cleanup]
> Date: Tue, 20 Jun 89 22:35:42 PDT
> From: Jon L White <jonl@lucid.com>
>
> Throughout all the thousands and thousands of lines of commentary on this
> topic, I've yet to see one that justified breaking the portability of
> SIMPLE-ARRAY.
I'm not convinced the breakage is really all that severe. By analogy,
we're now saying that at least a certain subset of INTEGERs are
guaranteed to be FIXNUMs, but an implementation may very well have
other numbers that are FIXNUMs too. People still seem to think that
FIXNUM declarations are useful and can be used portably. This
proposal is just saying that at least a certain subset of ARRAYs are
guaranteed to be SIMPLE-ARRAYs, but that an implementation is
permitted to have other things be SIMPLE-ARRAYs too.
The only thing that might be broken is if somebody is depending on an
array being of type (AND ARRAY (NOT SIMPLE-ARRAY)). But my
understanding is that, in current practice, this usage is already not
portable. I think that's justification enough for this aspect of the
proposal, although of course it has to be weighed against the
advantages of tightening the definition of SIMPLE-ARRAY.
> [In fact, I
> supported Kent's long-lost proposal that called for ADJUST-ARRAY to work
> like DELETE, returning a copy when it couldn't alter the array "in
> place". I had hoped that the :adjustable option to MAKE-ARRAY would
> thus acquire the meaning "adjustable in place".]
That is pretty much what the current proposal says for the behavior of
ADJUST-ARRAY, especially if the change I suggested (to disallow bashing
of the original array unless the return value is EQ to it) is adopted.
Incidentally, this also points out our motivation for wanting
ADJUSTABLE-ARRAY-P removed entirely. There isn't a corresponding
predicate to test whether DELETE would return a copy or alter the
array "in place", and people have been getting along without it just
fine.
-Sandra
-------
∂21-Jun-89 1507 CL-Cleanup-mailer Issue: BIT-ARRAY-FUNCTIONS (version 6)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 21 Jun 89 15:06:51 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 614570; 21 Jun 89 14:24:32 EDT
Date: Wed, 21 Jun 89 14:25 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: BIT-ARRAY-FUNCTIONS (version 6)
To: Barry Margolin <barmar@Think.COM>
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <19890619223922.8.BARMAR@OCCAM.THINK.COM>
Message-ID: <19890621182512.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 19 Jun 89 18:39 EDT
From: Barry Margolin <barmar@Think.COM>
Date: Mon, 19 Jun 89 13:44 EDT
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Date: Mon, 19 Jun 89 13:31 EDT
From: Barry Margolin <barmar@Think.COM>
I'd like to suggest an additional change, which seems to be consistent
with the attitude about use of bit vectors expressed in the proposal.
The BIT and SBIT functions should return 0 if asked to access outside
the bit array. This would maintain the tautology
(bit (bit-XXX v1 v2) n) == (logXXX (bit v1 n) (bit v2 n))
If slowing down these functions (they'd be the only array accessors
REQUIRED to check the dimensions) is considered unacceptable, then a new
accessor should be added.
I don't like this idea.
Could you elaborate? Why is it that you like the idea of assuming 0
elements on the end when combining bit vectors, but not when accessing
them? Either you think of them as being infinitely padded with zeros,
or you don't.
I disagree with the last sentence. I don't think the BIT function is in
the same category as the BIT-AND function, I think of it as being at a
different conceptual level. It's a matter of taste and intuition, so
I don't think I can explain it better, and I don't expect you to be
convinced. I'm only saying what I don't like, not what I think you
ought to dislike.
Then again, I have never used the BIT function and would propose to
remove it from the language if I thought that had a chance of passing.
Same for SBIT, CHAR, SCHAR, and SVREF.
I'm not sure I really grasp the whole motivation for this change.
Anyone who needs the kind of functionality being proposed can already
get it by using the boolean integer functions. They already provide the
infinitely-padded-with-zeroes feature. In fact, they also provide
infinitely-padded-with-ones, also, in the form of negative numbers.
The discussion that originally prompted this pointed out the reason why
the boolean integer functions aren't always adequate. I forget now what
it was, maybe the lack of control over consing, or maybe something more
fundamental. It looks like all that got into the writeup was a pointer
to that discussion, not a summary of it. Of course, that's the motivation
for having the BIT-AND etc. functions in the language in the first place,
more than the motivation for making this change to them.
∂21-Jun-89 1511 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 21 Jun 89 15:07:53 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 614688; 21 Jun 89 16:52:01 EDT
Date: Wed, 21 Jun 89 16:52 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 3)
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <22133.8906171550@aiai.ed.ac.uk>
Message-ID: <19890621205241.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sat, 17 Jun 89 16:50:44 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
What I wanted to do was just to change point 1 of step 8 on page 337
of CLtL, which is where unescaped constituents are converted to upper
case. At that point, characters are being considered one at a time.
If :INVERT's going to work on entire extended tokens, it looks like it
requires a more complicated change to the specification of READ.
Right. But the specification of READ should be how it behaves, not
a program-written-in-English.
If the read case of the current readtable is :INVERT and
if if all of the unescaped letters in the extended token are
of the same case, those letters are converted to the opposite
case.
Agreed. I think that's a good way to phrase it, too.
I'm a bit worried about the use of "unescaped" at this point,
since the other parts of the processing of extended token depend
only on attributes such as alphabetic or digit.
How about changing the places where it says escaped characters are given
the attribute alphabetic, and the places that say characters like ! and
= have the attribute alphabetic (obvious nonsense, eh?) to use the new
attribute name "ordinary". In fact there will no longer be an
alphabetic attribute, because all the letters have the alphadigit
attribute instead. But you'd have to switch 0 through 9 from alphadigit
to digit. Let's gloss over the impact, if any, on bases less than 10
(in octal, is 9 alphabetic?), otherwise we'd have to invent an
"ordinadigit" attribute for 0 through 9 to have.
So you could rephrase the rule:
If the read case of the current readtable is :INVERT and
if all of the alphabetic characters in the extended token are
of the same case, those characters are converted to the opposite
case.
That seems neater.
I'm also a bit worried about things like this:
\abc reads as aBC, but prints as Abc
This is inherent in the idea of escape characters, so you shouldn't
worry about it. Anyone who uses it to attack your proposal isn't
playing fair, they should be attacking CLtL Common Lisp for this
if they don't like it.
> Can you / will you write a version 4 that contains only the keywords
> proposal and that specifies :INVERT to invert case only when all the
> unescaped letters are in a single case?
Yes to at least the first. I'd like to have some more feedback on the
second.
I hope this is enough feedback. The amount of mail seems to be dying down.
∂21-Jun-89 1513 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 21 Jun 89 15:08:10 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 614692; 21 Jun 89 16:53:52 EDT
Date: Wed, 21 Jun 89 16:54 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 3)
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <22133.8906171550@aiai.ed.ac.uk>
Supersedes: <19890621205241.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comments: Didn't look carefully enough at your \abc example the first time.
Message-ID: <19890621205432.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sat, 17 Jun 89 16:50:44 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
What I wanted to do was just to change point 1 of step 8 on page 337
of CLtL, which is where unescaped constituents are converted to upper
case. At that point, characters are being considered one at a time.
If :INVERT's going to work on entire extended tokens, it looks like it
requires a more complicated change to the specification of READ.
Right. But the specification of READ should be how it behaves, not
a program-written-in-English.
If the read case of the current readtable is :INVERT and
if if all of the unescaped letters in the extended token are
of the same case, those letters are converted to the opposite
case.
Agreed. I think that's a good way to phrase it, too.
I'm a bit worried about the use of "unescaped" at this point,
since the other parts of the processing of extended token depend
only on attributes such as alphabetic or digit.
How about changing the places where it says escaped characters are given
the attribute alphabetic, and the places that say characters like ! and
= have the attribute alphabetic (obvious nonsense, eh?) to use the new
attribute name "ordinary". In fact there will no longer be an
alphabetic attribute, because all the letters have the alphadigit
attribute instead. But you'd have to switch 0 through 9 from alphadigit
to digit. Let's gloss over the impact, if any, on bases less than 10
(in octal, is 9 alphabetic?), otherwise we'd have to invent an
"ordinadigit" attribute for 0 through 9 to have.
So you could rephrase the rule:
If the read case of the current readtable is :INVERT and
if all of the alphabetic characters in the extended token are
of the same case, those characters are converted to the opposite
case.
That seems neater.
I'm also a bit worried about things like this:
\abc reads as aBC, but prints as Abc
This is inherent in the idea of escape characters, so you shouldn't
worry about it. Anyone who uses it to attack your proposal isn't
playing fair, they should be attacking CLtL Common Lisp for this
if they don't like it.
Oh excuse me, it can't print as Abc since that reads as Abc.
It has to print as aBC or |aBC|. Any printer has to be able to
figure out whether it has to put in escapes to make the reader
read it back correctly, so that's no problem.
> Can you / will you write a version 4 that contains only the keywords
> proposal and that specifies :INVERT to invert case only when all the
> unescaped letters are in a single case?
Yes to at least the first. I'd like to have some more feedback on the
second.
I hope this is enough feedback. The amount of mail seems to be dying down.
∂21-Jun-89 1548 CL-Cleanup-mailer Issue SUBTYPEP-TOO-VAGUE, version 5
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 21 Jun 89 15:48:49 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 614830; 21 Jun 89 18:50:31 EDT
Date: Wed, 21 Jun 89 18:51 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue SUBTYPEP-TOO-VAGUE, version 5
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <890621-103047-17283@Xerox>
Message-ID: <19890621225112.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
I overlooked this one because my database has it marked as accepted,
even though the database does indicate informally that after it was
accepted an amendment was proposed that has not yet been acted upon.
I wonder how many others there are in that category?
∂21-Jun-89 1732 CL-Cleanup-mailer Issue: BIT-ARRAY-FUNCTIONS (version 6)
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 21 Jun 89 17:32:18 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Wed, 21 Jun 89 16:05:08 EDT
Date: Wed, 21 Jun 89 16:03 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: BIT-ARRAY-FUNCTIONS (version 6)
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <19890621182512.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <19890621200319.9.BARMAR@OCCAM.THINK.COM>
Date: Wed, 21 Jun 89 14:25 EDT
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Date: Mon, 19 Jun 89 18:39 EDT
From: Barry Margolin <barmar@Think.COM>
Date: Mon, 19 Jun 89 13:44 EDT
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Date: Mon, 19 Jun 89 13:31 EDT
From: Barry Margolin <barmar@Think.COM>
I'd like to suggest an additional change, which seems to be consistent
with the attitude about use of bit vectors expressed in the proposal.
The BIT and SBIT functions should return 0 if asked to access outside
the bit array. This would maintain the tautology
(bit (bit-XXX v1 v2) n) == (logXXX (bit v1 n) (bit v2 n))
If slowing down these functions (they'd be the only array accessors
REQUIRED to check the dimensions) is considered unacceptable, then a new
accessor should be added.
I don't like this idea.
Could you elaborate? Why is it that you like the idea of assuming 0
elements on the end when combining bit vectors, but not when accessing
them? Either you think of them as being infinitely padded with zeros,
or you don't.
I disagree with the last sentence. I don't think the BIT function is in
the same category as the BIT-AND function, I think of it as being at a
different conceptual level.
That was why I suggested the possibility of inventing a new function for
this purpose (although the reason I gave wasn't complete).
I just can't think of a good name that would make it obvious that one is
just a pre-optimized bit array accessor and the other is for accessing
conceptually infinite bit vectors (or bit arrays, if the other part of
the proposal passes).
barmar
∂21-Jun-89 1835 CL-Cleanup-mailer Issue: PATHNAME-LOGICAL (version 3)
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 21 Jun 89 18:35:27 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Wed, 21 Jun 89 21:36:17 EDT
Date: Wed, 21 Jun 89 21:34 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: PATHNAME-LOGICAL (version 3)
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <19890621161905.6.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Message-Id: <19890622013420.6.BARMAR@OCCAM.THINK.COM>
10. TRANSLATE-LOGICAL-PATHNAME pathname [Function]
If the coerced argument is a logical pathname, the first matching
translation (according to PATHNAME-MATCH-P) of the logical pathname
host is applied, using TRANSLATE-PATHNAME with the reversible argument
true. If the result is a logical pathname, this process is repeated.
Three values are returned:
1. The physical pathname
2. The from-wildcard of the translation
3. The to-wildcard of the translation
If the translation process has to be repeated, which wildcards are
returned as values 2 and 3, the first or the last? It seems to me that
in order to be useful, this must return the entire sequence of wildcard
pairs that were used. The description later says:
they might be
modified to reflect multiple levels of translation and/or additional
translations
Maybe this is answering my question, but I'm unsure whether a single
pair of wildcards can represent a sequence of translations; I guess the
question is whether wildcard translations form a group, or something
like that (my math theory is a bit rusty).
Also, I expect that there are some translations that simply can't be
represented as wildcard translations. For instance, Genera translates
SYS:<system>;PATCH;<system>-<version#>-<patch#>.<type>
to
SYS:<system>;PATCH;<system>-<version>;<system>-<version#>-<patch#>.<type>
which requires at least something as powerful as regular expressions
with variables. I'm not saying that the portable logical pathname
facility must allow the programmer to implement the above translation;
I'm wondering what Genera will return as values 2 and 3 in the case
where a patch file pathname is given to TRANSLATE-LOGICAL-PATHNAME.
I suppose this can be done using wildcards, since there's no restriction
on how complex an implementation's wildcard facility may be (it could
include variables, for instance). But current practice is to perform
some complex translations outside the wildcard translation mechanism
(and in Genera, one could define a subclass of FS:LOGICAL-HOST that
incorporates arbitrary translation rules).
barmar
∂21-Jun-89 2208 CL-Cleanup-mailer Re: Issue: MAP-INTO (version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Jun 89 22:08:05 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 21 JUN 89 22:07:44 PDT
Date: 21 Jun 89 22:07 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: MAP-INTO (version 2)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Mon, 19 Jun 89 12:16 EDT
To: CL-Cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <890621-220744-18699@Xerox>
I liked Kim's idea (add transformation function keyword to REPLACE) better
than this proposal....
can't you do this with LOOP, anyway?
∂22-Jun-89 1043 CL-Cleanup-mailer Issue: PATHNAME-LOGICAL (version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 22 Jun 89 10:43:14 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 615296; 22 Jun 89 13:44:50 EDT
Date: Thu, 22 Jun 89 13:45 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-LOGICAL (version 3)
To: Barry Margolin <barmar@Think.COM>
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <19890622013420.6.BARMAR@OCCAM.THINK.COM>
Message-ID: <19890622174528.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 21 Jun 89 21:34 EDT
From: Barry Margolin <barmar@Think.COM>
10. TRANSLATE-LOGICAL-PATHNAME pathname [Function]
If the coerced argument is a logical pathname, the first matching
translation (according to PATHNAME-MATCH-P) of the logical pathname
host is applied, using TRANSLATE-PATHNAME with the reversible argument
true. If the result is a logical pathname, this process is repeated.
Three values are returned:
1. The physical pathname
2. The from-wildcard of the translation
3. The to-wildcard of the translation
If the translation process has to be repeated, which wildcards are
returned as values 2 and 3, the first or the last?
Neither.
It seems to me that
in order to be useful, this must return the entire sequence of wildcard
pairs that were used. The description later says:
they might be
modified to reflect multiple levels of translation and/or additional
translations
Maybe this is answering my question, but I'm unsure whether a single
pair of wildcards can represent a sequence of translations; I guess the
question is whether wildcard translations form a group, or something
like that (my math theory is a bit rusty).
That text was supposed to answer your question, as was the example that
begins ";For Unix with 14-character file names, using .l as the type".
In retrospect it wasn't nearly as clear as it should have been.
The fact that I think you are overlooking is that the -only- requirement
on the second and third values from TRANSLATE-LOGICAL-PATHNAME is the
identity given in point 10 of the proposal. They do not have to be
general wildcards that can translate -anything- back to a logical pathname,
the proposal only requires them to work for the particular physical
pathname that was returned. Thus to-wildcard could be equal to the
physical pathname and from-wildcard could be equal to the logical pathname.
This would translate that one physical pathname back to that one logical
pathname.
Of course it's better if an implementation returns more generally useful
wildcard pathnames; I wanted to formulate a stronger constraint on the
implementation but couldn't think of one. The best I've been able to do
so far is that if component X has a value of :WILD (or NIL) in every
level of translation, then component X in the result should be :WILD;
apply this rule separately to from and to. Should this be put in to
the proposal by amendment, or am I trying to overspecify here?
The other possibility would be to eliminate all support for back
translation by eliminating the extra return values from TRANSLATE-PATHNAME
and TRANSLATE-LOGICAL-PATHNAME (we would add these functions to the list
that implementations are allowed to extend by adding extra values).
This would certainly simplify things and might be for the best.
The more I think about it the more I like this idea, perhaps I'll come
to the meeting prepared with amendments to these two proposals.
∂22-Jun-89 1131 CL-Cleanup-mailer Issue: READ-CASE-SENSITIVITY (Version 4)
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 22 Jun 89 11:31:29 PDT
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP
id aa08257; 22 Jun 89 19:21 BST
Date: Thu, 22 Jun 89 19:32:17 BST
Message-Id: <23126.8906221832@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: Issue: READ-CASE-SENSITIVITY (Version 4)
To: "David A. Moon" <Moon@stony-brook.scrc.symbolics.com>
In-Reply-To: David A. Moon's message of Wed, 21 Jun 89 16:54 EDT
Cc: cl-cleanup@sail.stanford.edu
Maybe this is OK. If anyone has objections, I'd really like to hear
them before everyone goes off to the meeting. (Um, I know it's rather
late.)
Issue: READ-CASE-SENSITIVITY
Forum: Cleanup
References: CLtL p 334 ff: What the Read Function Accepts,
especially p 337, step 8, point 1.
CLtL p 360 ff: The Readtable
COPY-READTABLE (CLtL, p 361)
*PRINT-CASE* (CLtL, p 372)
Category: ADDITION/CHANGE
Edit history: Version 1, 15-Feb-89, by Dalton
Version 2, 23-Mar-89, by Dalton,
(completely new proposal after comments from
Pitman, Gray, Masinter, and R.Tobin@uk.ac.ed)
Version 3, 16-Jun-89, by Dalton
(very minor changes in presentation
and some additions to the discussion)
Version 4, 22-Jun-89, by Dalton
(removal of the FUNCTION proposal and a different
specification for :INVERT after discussion with Moon)
Problem Description:
The Common Lisp reader always converts unescaped constituent
characters to upper case. (See CLtL, p 337, step 8, point 1.)
This behavior is not always desirable.
1. Lisp applications often use the Lisp reader to read their data.
This is often significantly easier than writing input routines
from scratch, especially if the input can be structured as lists.
However, certain applications want to make use of case distinctions,
and Common Lisp makes this unreasonably difficult. (You must define
every letter as a read macro and have the macro function read the
rest of the symbol, or else you must write a reader from scratch.)
2. Some programming languages distinguish between upper and lower
case in identifiers, and useful conventions are often built around
such distinctions. For example, in C, constants are often written
in upper case and variables in lower. In Mesa(?) and Smalltalk(?),
a capital letter is used to indicate the beginning of a new word
in identifiers made up of several words. In Edinburgh Prolog,
variables begin with upper-case letters and constant symbols do
not. The case-insensitivity of the Common Lisp reader makes
it difficult to use conventions of this sort.
Proposal (READ-CASE-SENSITIVITY:READTABLE-KEYWORDS)
Define a new settable function, (READTABLE-CASE <readtable>) to
control the reader's interpretation of case. The following values
may be given: :UPCASE, :DOWNCASE, :PRESERVE, and :INVERT.
When the value is :UPCASE, unescaped constituent characters
are converted to upper-case, as specified by CLtL on page 337.
When the value is :DOWNCASE, unescaped constituent characters
are converted to lower-case.
When the value is :PRESERVE, the case of all characters remains
unchanged.
When the value is :INVERT, then if if all of the unescaped letters
in the extended token are of the same case, those (unescaped)
letters are converted to the opposite case.
COPY-READTABLE copies the setting of READTABLE-CASE. The value of
READTABLE-CASE for the standard readtable is :UPCASE.
The READTABLE-CASE of a readtable also has significance when
printing. The case in which letters are printed is determined as
follows:
When READTABLE-CASE is :UPCASE, upper-case letters are printed
in the case specified by *PRINT-CASE*, and lower-case letters
are printed in their own case.
When READTABLE-CASE is :DOWNCASE, lower-case letters are printed
in the case specified by *PRINT-CASE*, and upper-case letters
are printed in their own case.
When READTABLE-CASE is :PRESERVE, all letters are printed in their
own case.
When READTABLE-CASE is :INVERT, the case of all letters in single-
case symbol names is inverted. Mixed-case symbol names are printed
as-is.
(The behavior when *PRINT-CASE* is :CAPITALIZE is like :UPCASE for
the first character and :DOWNCASE for the rest.)
The rules for escaping letters in symbol names are also affected by
the READTABLE-CASE. If *PRINT-ESCAPE* is true, letters are escaped
as follows:
When READTABLE-CASE is :UPCASE, all lower-case letters must be
escaped.
When READTABLE-CASE is :DOWNCASE, all upper-case letters must be
escaped.
When READTABLE-CASE is :PRESERVE, no letters need be escaped.
When READTABLE-CASE is :INVERT, all letters in all single-case
symbol names must be escaped.
Rationale:
There are a number of different ways to achieve case-sensitivity.
This proposal is fairly simple but provides all of the functionality
that one could reasonably expect.
By using a property of the readtable, we avoid introducing a new
special variable. Any code that wishes to control all of the
reader's parameters already takes *READTABLE* into account. A new
special variable would require such code to change.
:DOWNCASE is included for symmetry with :UPCASE.
:INVERT is included so that case conventions can be used in Common
Lisp code without requiring that the names of symbols in the "LISP"
package be written in upper case. (Opinions vary as to whether is
is advisable to use such conventions, but this proposal leaves that
choice to the user.)
:INVERT has an effect only for single-case names so that mixed-
case names can be interpreted in a more straightforward way.
In order to avoid complex interactions between the case setting of
the readtable and *PRINT-CASE*, this proposal specifies a
significance for *PRINT-CASE* only when the case setting is :UPCASE
or :DOWNCASE. The meaning of *PRINT-CASE* when the readtable
setting is :DOWNCASE was chosen for its simplicity and for symmetry
with :UPCASE while still being useful.
Test Case:
(let ((rt (copy-readtable nil)))
(mapcar
#'(lambda (case)
(setf (readtable-case rt) case)
(read-from-string "Zebra"))
'(:upcase :downcase :preserve :invert)))
=> (ZEBRA |zebra| |Zebra| |zEBRA|) ;as printed with the standard
;readtable and *print-case* :upcase
Current Practice:
While there may not be any current implementation that supports
exactly this proposal, several implementations provide some means
for changing case sensitivity.
Franz Inc's ExCL has a function, EXCL:SET-CASE-MODE, that sets both
the "preferred case" (the case of characters in the print names of
standard symbols such as CAR) and whether or not the reader is case-
sensitive.
In Symbolics Common Lisp, the function SET-CHARACTER-TRANSLATION
can be used to make the translation of a letter be that same letter,
thus achieving case-sensitivity.
Xerox Medley has a function for setting a readtable flag that
determines case sensitivity.
Cost to Implementors:
Fairly small. The reader will be slightly slower and readtables
will be slightly more complex.
Cost to Users:
Slight. Programmers must already take into account the possibility
that *READTABLE* will be a non-standard readtable. Case-sensitivity
is no worse than character macros in this respect.
Cost of Non-Adoption:
Applications that want to read mixed-case expressions will not
be able to use the Common Lisp reader to do so (except, perhaps,
by tortuous use of read macros).
Programming styles that rely on case distinctions (without escape
characters) will effectively be impossible in Common Lisp.
Benefits:
Applications will be able to read mixed-case expressions.
Programmers will be able to make use of case distinctions.
Aesthetics:
For the proposal:
The language will have greater symmetry, because it will be
possible to control the treatment of case on both input and output
instead of only on output (as is now the case).
The language will look less old-fashioned.
Against the proposal:
It is, perhaps, inconsistent to control case-sensitivity by a
readtable operation when other aspects of the reader, such as the
input base and the default float format (not to mention the
package), are controlled by special variables. However, it can be
argued that character-level syntax is determined chiefly by the
readtable. Case-sensitivity can be seen as analogous to character
macros in this respect.
Discussion:
Dalton supports the proposal READTABLE-KEYWORDS.
Version 1 of the proposal suggested a new global variable rather
than a property of the readtable. Pitman was strongly opposed to
that proposal and gave convincing arguments that it should be
dropped. Gray suggested that the readtable property should be a
function. Versions 2 and 3 included a FUNCTION proposal as well
as the KEYWORD one. But at the March 1989 X3J13 meeting it was
felt that there should be only a single proposal and, since
opinion seemed to favor the KEYWORD proposal, the FUNCTION
proposal was dropped.
In earlier versions of the proposal, :INVERT worked a letter at
a time (rather than operating on extended tokens) so that, for
example, Zebra read as zEBRA. However, the purpose of :INVERT
is to let the programmer get the standard internal case (ie,
upper case) by writing lower case rather than upper. This
matters when referring to single-case symbols such as those
in the LISP package. But, in most cases, mixed-case identifiers
will already have the right case. For example, one would use
TheNextWindow to get TheNextWindow, not tHEnEXTwINDOW.
∂22-Jun-89 1159 CL-Cleanup-mailer Issue: PATHNAME-LOGICAL (version 3)
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 22 Jun 89 11:59:08 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Thu, 22 Jun 89 14:59:42 EDT
Date: Thu, 22 Jun 89 14:57 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: PATHNAME-LOGICAL (version 3)
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <19890622174528.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <19890622185756.5.BARMAR@OCCAM.THINK.COM>
Date: Thu, 22 Jun 89 13:45 EDT
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Thus to-wildcard could be equal to the
physical pathname and from-wildcard could be equal to the logical pathname.
This would translate that one physical pathname back to that one logical
pathname.
Yes, that possibility finally occurred to me after I sent off my
message.
The other possibility would be to eliminate all support for back
translation by eliminating the extra return values from TRANSLATE-PATHNAME
and TRANSLATE-LOGICAL-PATHNAME (we would add these functions to the list
that implementations are allowed to extend by adding extra values).
This would certainly simplify things and might be for the best.
The more I think about it the more I like this idea, perhaps I'll come
to the meeting prepared with amendments to these two proposals.
I'm leaning that way, too. An application that needs to do back
translation can always maintain its own hash table of all the
translations that have been done.
barmar
∂22-Jun-89 1403 CL-Cleanup-mailer Issue: READ-CASE-SENSITIVITY (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 22 Jun 89 14:02:50 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 615489; 22 Jun 89 17:04:24 EDT
Date: Thu, 22 Jun 89 17:04 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: READ-CASE-SENSITIVITY (Version 4)
To: jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@sail.stanford.edu
In-Reply-To: <23126.8906221832@subnode.aiai.ed.ac.uk>
Message-ID: <19890622210419.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Mostly this still looks ok to me. I will certainly encourage Moon to
vote Yes on it. But I do have a few comments which I think would both
improve the presentation and would help us avoid confusions down the
road...
Date: Thu, 22 Jun 89 19:32:17 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Maybe this is OK. If anyone has objections, I'd really like to hear
them before everyone goes off to the meeting. (Um, I know it's rather
late.)
Issue: READ-CASE-SENSITIVITY
...
Proposal (READ-CASE-SENSITIVITY:READTABLE-KEYWORDS)
...
The READTABLE-CASE of a readtable also has significance when
printing. The case in which letters are printed is determined as
follows:
When READTABLE-CASE is :UPCASE, upper-case letters are printed
in the case specified by *PRINT-CASE*, and lower-case letters
are printed in their own case.
When READTABLE-CASE is :DOWNCASE, lower-case letters are printed
in the case specified by *PRINT-CASE*, and upper-case letters
are printed in their own case.
When READTABLE-CASE is :PRESERVE, all letters are printed in their
own case.
When READTABLE-CASE is :INVERT, the case of all letters in single-
case symbol names is inverted. Mixed-case symbol names are printed
as-is.
(The behavior when *PRINT-CASE* is :CAPITALIZE is like :UPCASE for
the first character and :DOWNCASE for the rest.)
...
I think this parenthetic remark is more confusing than helpful.
For example, it only applies in the cases of READTABLE-CASE
being :UPCASE or :DOWNCASE, right? Strictly, I think it is not
necessary because the phrase "in the case specified by *PRINT-CASE*"
means this. If you really feel the remark is needed, I suggest the
notation:
The READTABLE-CASE of a readtable also has significance when
printing. The case in which letters are printed is determined as
follows:
When READTABLE-CASE is :UPCASE, upper-case letters are printed
in the case specified by *PRINT-CASE* [1], and lower-case letters
are printed in their own case.
When READTABLE-CASE is :DOWNCASE, lower-case letters are printed
in the case specified by *PRINT-CASE* [1], and upper-case letters
are printed in their own case.
When READTABLE-CASE is :PRESERVE, all letters are printed in their
own case.
When READTABLE-CASE is :INVERT, the case of all letters in single-
case symbol names is inverted. Mixed-case symbol names are printed
as-is.
[1] That is, :UPCASE means uppercase, :DOWNCASE means lowercase,
and :CAPITALIZE means uppercase for the first character and
lowercase for the rest of the characters.
...
-----
Test Case:
(let ((rt (copy-readtable nil)))
(mapcar
#'(lambda (case)
(setf (readtable-case rt) case)
(read-from-string "Zebra"))
'(:upcase :downcase :preserve :invert)))
=> (ZEBRA |zebra| |Zebra| |zEBRA|) ;as printed with the standard
;readtable and *print-case* :upcase
This example is buggy, of course, because you need to bind *READTABLE*, not RT.
It's also incomplete because it doesn't explain the interaction with *PRINT-CASE*.
It would be better if we had a test case which at least did:
(let ((*readtable* (copy-readtable nil))
(*print-case* *print-case*)
(readtable-cases '(:upcase :downcase :preserve :invert))
(print-cases '(:upcase :downcase :capitalize)))
(format t "READTABLE-CASE *PRINT-CASE* ZEBRA Zebra zebra zEBRA~
~%----------------------------------------------------------~
~%")
(dolist (readtable-case readtable-cases)
(dolist (print-case print-cases)
(let ((data '()))
(setf (readtable-case *readtable*) readtable-case)
(setq *print-case* print-case)
(dolist (string '("ZEBRA" "Zebra" "zebra" "zEBRA"))
(push (read-from-string string) data))
(setq data (nreverse data))
(setf (readtable-case *readtable*) readtable-case)
(format t "~&:~A~16T:~A~32T ~{~A~↑ ~}"
(string-upcase readtable-case)
(string-upcase print-case)
data)))))
Actually, a full table like the following might be even clearer, but maybe
that's overkill...
(let ((*readtable* (copy-readtable nil))
(*print-case* *print-case*)
(readtable-cases '(:upcase :downcase :preserve :invert))
(print-cases '(:upcase :downcase :capitalize)))
(format t "READTABLE-CASE *PRINT-CASE* Input:~
~%Read Print Print ZEBRA Zebra zebra zEBRA~
~%--------------------------------------------------------------~
~%")
(dolist (readtable-case-for-read-time readtable-cases)
(dolist (readtable-case-for-print-time readtable-cases)
(dolist (print-case-for-print-time print-cases)
(let ((data '()))
(setf (readtable-case *readtable*) readtable-case-for-read-time)
(dolist (string '("ZEBRA" "Zebra" "zebra" "zEBRA"))
(push (read-from-string string) data))
(setq data (nreverse data))
(setf (readtable-case *readtable*) readtable-case-for-print-time)
(setq *print-case* print-case-for-print-time)
(format t "~&:~A~12T:~A~24T:~A~36T ~{~A~↑ ~}"
(string-upcase readtable-case-for-read-time)
(string-upcase readtable-case-for-print-time)
(string-upcase print-case-for-print-time)
data))))))
∂23-Jun-89 0550 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 4)
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 23 Jun 89 05:50:21 PDT
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP
id aa06167; 23 Jun 89 13:25 BST
Date: Fri, 23 Jun 89 13:36:11 BST
Message-Id: <425.8906231236@aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 4)
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
In-Reply-To: Kent M Pitman's message of Thu, 22 Jun 89 17:04 EDT
Cc: Moon@stony-brook.scrc.symbolics.com, cl-cleanup@sail.stanford.edu
> Mostly this still looks ok to me. I will certainly encourage Moon to
> vote Yes on it. But I do have a few comments which I think would both
> improve the presentation and would help us avoid confusions down the
> road...
>
> Date: Thu, 22 Jun 89 19:32:17 BST
> From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
>
> Issue: READ-CASE-SENSITIVITY
> ...
> Proposal (READ-CASE-SENSITIVITY:READTABLE-KEYWORDS)
> ...
> The READTABLE-CASE of a readtable also has significance when
> printing. The case in which letters are printed is determined as
> follows:
> ...
> (The behavior when *PRINT-CASE* is :CAPITALIZE is like :UPCASE for
> the first character and :DOWNCASE for the rest.)
> ...
>
> I think this parenthetic remark is more confusing than helpful.
I think you're right. When I try to read it closely, I find that
I'm confused, and since I wrote it that should count. It looks
like it might be trying to say something interesting when it
isn't.
> For example, it only applies in the cases of READTABLE-CASE
> being :UPCASE or :DOWNCASE, right?
Right.
> Strictly, I think it is not necessary because the phrase "in the
> case specified by *PRINT-CASE*" means this.
I agree.
> If you really feel the remark is needed, I suggest the
> notation:
> [1] That is, :UPCASE means uppercase, :DOWNCASE means lowercase,
> and :CAPITALIZE means uppercase for the first character and
> lowercase for the rest of the characters.
I think I'll try just taking it out.
> -----
> Test Case:
>
> (let ((rt (copy-readtable nil)))
> (mapcar
> #'(lambda (case)
> (setf (readtable-case rt) case)
> (read-from-string "Zebra"))
> '(:upcase :downcase :preserve :invert)))
>
> => (ZEBRA |zebra| |Zebra| |zEBRA|) ;as printed with the standard
> ;readtable and *print-case* :upcase
>
> This example is buggy, of course, because you need to bind
> *READTABLE*, not RT.
I must have made a mistake in editing at some point.
> It's also incomplete because it doesn't explain the interaction with
> *PRINT-CASE*.
What I wanted to do in the test case was just to show what internal
symbol-name was obtained given a setting for the READTABLE-CASE.
Perhaps I should do that more explicitly by showing the value returned
by SYMBOL-NAME. But maybe I have to show the effect of *PRINT-ESCAPE*
too, which does happen in the current test case (though I think
what I have is now over-cautious.
> It would be better if we had a test case which at least did:
I'm a bit worried about running out of time. I'll try to send
something better out later today, but I'm not sure I'll have time
to do a full set of test cases.
Thanks for you comments. They are vary helpful.
-- Jeff
∂23-Jun-89 1840 CL-Cleanup-mailer Issue: READ-CASE-SENSITIVITY (Version 5)
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 23 Jun 89 18:40:19 PDT
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP
id aa09938; 23 Jun 89 21:20 BST
Date: Fri, 23 Jun 89 21:30:23 BST
Message-Id: <3406.8906232030@aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: Issue: READ-CASE-SENSITIVITY (Version 5)
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
In-Reply-To: Kent M Pitman's message of Thu, 22 Jun 89 17:04 EDT
Cc: Moon@stony-brook.scrc.symbolics.com, cl-cleanup@sail.stanford.edu
Issue: READ-CASE-SENSITIVITY
Forum: Cleanup
References: CLtL p 334 ff: What the Read Function Accepts,
especially p 337, step 8, point 1.
CLtL p 360 ff: The Readtable
COPY-READTABLE (CLtL, p 361)
*PRINT-CASE* (CLtL, p 372)
Category: ADDITION/CHANGE
Edit history: Version 1, 15-Feb-89, by Dalton
Version 2, 23-Mar-89, by Dalton,
(completely new proposal after comments from
Pitman, Gray, Masinter, and R.Tobin@uk.ac.ed)
Version 3, 16-Jun-89, by Dalton
(very minor changes in presentation
and some additions to the discussion)
Version 4, 22-Jun-89, by Dalton
(removal of the FUNCTION proposal and a different
specification for :INVERT after discussion with Moon)
Version 5, 23-Jun-89, by Dalton
(minor revisions in presentation and better test case,
as suggested by Pitman; also fixed some other errors)
Problem Description:
The Common Lisp reader always converts unescaped constituent
characters to upper case. (See CLtL, p 337, step 8, point 1.)
This behavior is not always desirable.
1. Lisp applications often use the Lisp reader to read their data.
This is often significantly easier than writing input routines
from scratch, especially if the input can be structured as lists.
However, certain applications want to make use of case distinctions,
and Common Lisp makes this unreasonably difficult. (You must define
every letter as a read macro and have the macro function read the
rest of the symbol, or else you must write a reader from scratch.)
2. Some programming languages distinguish between upper and lower
case in identifiers, and useful conventions are often built around
such distinctions. For example, in C, constants are often written
in upper case and variables in lower. In Mesa(?) and Smalltalk(?),
a capital letter is used to indicate the beginning of a new word
in identifiers made up of several words. In Edinburgh Prolog,
variables begin with upper-case letters and constant symbols do
not. The case-insensitivity of the Common Lisp reader makes
it difficult to use conventions of this sort.
Proposal (READ-CASE-SENSITIVITY:READTABLE-KEYWORDS)
Define a new settable function, (READTABLE-CASE <readtable>) to
control the reader's interpretation of case. The following values
may be given: :UPCASE, :DOWNCASE, :PRESERVE, and :INVERT.
When the value is :UPCASE, unescaped constituent characters
are converted to upper-case, as specified by CLtL on page 337.
When the value is :DOWNCASE, unescaped constituent characters
are converted to lower-case.
When the value is :PRESERVE, the case of all characters remains
unchanged.
When the value is :INVERT, then if all of the unescaped letters
in the extended token are of the same case, those (unescaped)
letters are converted to the opposite case.
COPY-READTABLE copies the setting of READTABLE-CASE. The value of
READTABLE-CASE for the standard readtable is :UPCASE.
The READTABLE-CASE of a readtable also has significance when printing
The case in which letters are printed, when vertical-bar syntax is not
used, is determined as follows:
When READTABLE-CASE is :UPCASE, upper-case letters are printed
in the case specified by *PRINT-CASE*, and lower-case letters
are printed in their own case.
When READTABLE-CASE is :DOWNCASE, lower-case letters are printed
in the case specified by *PRINT-CASE*, and upper-case letters
are printed in their own case.
When READTABLE-CASE is :PRESERVE, all letters are printed in their
own case.
When READTABLE-CASE is :INVERT, the case of all letters in single-
case symbol names is inverted. Mixed-case symbol names are printed
as-is.
The rules for escaping letters in symbol names are also affected by
the READTABLE-CASE. If *PRINT-ESCAPE* is true, letters are escaped
as follows:
When READTABLE-CASE is :UPCASE, all lower-case letters must be
escaped.
When READTABLE-CASE is :DOWNCASE, all upper-case letters must be
escaped.
When READTABLE-CASE is :PRESERVE, no letters need be escaped.
When READTABLE-CASE is :INVERT, all letters in all single-case
symbol names must be escaped.
Rationale:
There are a number of different ways to achieve case-sensitivity.
This proposal is fairly simple but provides all of the functionality
that one could reasonably expect.
By using a property of the readtable, we avoid introducing a new
special variable. Any code that wishes to control all of the
reader's parameters already takes *READTABLE* into account. A new
special variable would require such code to change.
:DOWNCASE is included for symmetry with :UPCASE.
:INVERT is included so that case conventions can be used in Common
Lisp code without requiring that the names of symbols in the "LISP"
package be written in upper case. (Opinions vary as to whether is
is advisable to use such conventions, but this proposal leaves that
choice to the user.)
:INVERT has an effect only for single-case names so that mixed-
case names can be interpreted in a more straightforward way.
In order to avoid complex interactions between the case setting of
the readtable and *PRINT-CASE*, this proposal specifies a
significance for *PRINT-CASE* only when the case setting is :UPCASE
or :DOWNCASE. The meaning of *PRINT-CASE* when the readtable
setting is :DOWNCASE was chosen for its simplicity and for symmetry
with :UPCASE while still being useful.
Test Cases:
;;; Test 1 -- reading
(defun test1 ()
(let ((*readtable* (copy-readtable nil)))
(format t "READTABLE-CASE Input Symbol-name~
~%-----------------------------------~
~%")
(dolist (readtable-case '(:upcase :downcase :preserve :invert))
(setf (readtable-case *readtable*) readtable-case)
(dolist (input '("ZEBRA" "Zebra" "zebra"))
(format t "~&:~A~16T~A~24T~A"
(string-upcase readtable-case)
input
(symbol-name (read-from-string input)))))))
The output from (TEST1) should be as follows:
READTABLE-CASE Input Symbol-name
-----------------------------------
:UPCASE ZEBRA ZEBRA
:UPCASE Zebra ZEBRA
:UPCASE zebra ZEBRA
:DOWNCASE ZEBRA zebra
:DOWNCASE Zebra zebra
:DOWNCASE zebra zebra
:PRESERVE ZEBRA ZEBRA
:PRESERVE Zebra Zebra
:PRESERVE zebra zebra
:INVERT ZEBRA zebra
:INVERT Zebra Zebra
:INVERT zebra ZEBRA
;;; Test 2 -- printing
(defun test2 ()
(let ((*readtable* (copy-readtable nil))
(*print-case* *print-case*))
(format t "READTABLE-CASE *PRINT-CASE* Symbol-name Output~
~%--------------------------------------------------~
~%")
(dolist (readtable-case '(:upcase :downcase :preserve :invert))
(setf (readtable-case *readtable*) readtable-case)
(dolist (print-case '(:upcase :downcase :capitalize))
(dolist (symbol '(|ZEBRA| |Zebra| |zebra|))
(setq *print-case* print-case)
(format t "~&:~A~15T:~A~29T~A~42T~A"
(string-upcase readtable-case)
(string-upcase print-case)
(symbol-name symbol)
(prin1-to-string symbol)))))))
The putput from (TEST2) should be as follows:
READTABLE-CASE *PRINT-CASE* Symbol-name Output
--------------------------------------------------
:UPCASE :UPCASE ZEBRA ZEBRA
:UPCASE :UPCASE Zebra |Zebra|
:UPCASE :UPCASE zebra |zebra|
:UPCASE :DOWNCASE ZEBRA zebra
:UPCASE :DOWNCASE Zebra |Zebra|
:UPCASE :DOWNCASE zebra |zebra|
:UPCASE :CAPITALIZE ZEBRA Zebra
:UPCASE :CAPITALIZE Zebra |Zebra|
:UPCASE :CAPITALIZE zebra |zebra|
:DOWNCASE :UPCASE ZEBRA |ZEBRA|
:DOWNCASE :UPCASE Zebra |Zebra|
:DOWNCASE :UPCASE zebra ZEBRA
:DOWNCASE :DOWNCASE ZEBRA |ZEBRA|
:DOWNCASE :DOWNCASE Zebra |Zebra|
:DOWNCASE :DOWNCASE zebra zebra
:DOWNCASE :CAPITALIZE ZEBRA |ZEBRA|
:DOWNCASE :CAPITALIZE Zebra |Zebra|
:DOWNCASE :CAPITALIZE zebra Zebra
:PRESERVE :UPCASE ZEBRA ZEBRA
:PRESERVE :UPCASE Zebra Zebra
:PRESERVE :UPCASE zebra zebra
:PRESERVE :DOWNCASE ZEBRA ZEBRA
:PRESERVE :DOWNCASE Zebra Zebra
:PRESERVE :DOWNCASE zebra zebra
:PRESERVE :CAPITALIZE ZEBRA ZEBRA
:PRESERVE :CAPITALIZE Zebra Zebra
:PRESERVE :CAPITALIZE zebra zebra
:INVERT :UPCASE ZEBRA zebra
:INVERT :UPCASE Zebra Zebra
:INVERT :UPCASE zebra ZEBRA
:INVERT :DOWNCASE ZEBRA zebra
:INVERT :DOWNCASE Zebra Zebra
:INVERT :DOWNCASE zebra ZEBRA
:INVERT :CAPITALIZE ZEBRA zebra
:INVERT :CAPITALIZE Zebra Zebra
:INVERT :CAPITALIZE zebra ZEBRA
Current Practice:
While there may not be any current implementation that supports
exactly this proposal, several implementations provide some means
for changing case sensitivity.
Franz Inc's ExCL has a function, EXCL:SET-CASE-MODE, that sets both
the "preferred case" (the case of characters in the print names of
standard symbols such as CAR) and whether or not the reader is case-
sensitive.
In Symbolics Common Lisp, the function SET-CHARACTER-TRANSLATION
can be used to make the translation of a letter be that same letter,
thus achieving case-sensitivity.
Xerox Medley has a function for setting a readtable flag that
determines case sensitivity.
Cost to Implementors:
Fairly small. The reader will be slightly slower and readtables
will be slightly more complex.
Cost to Users:
Slight. Programmers must already take into account the possibility
that *READTABLE* will be a non-standard readtable. Case-sensitivity
is no worse than character macros in this respect.
Cost of Non-Adoption:
Applications that want to read mixed-case expressions will not
be able to use the Common Lisp reader to do so (except, perhaps,
by tortuous use of read macros).
Programming styles that rely on case distinctions (without escape
characters) will effectively be impossible in Common Lisp.
Benefits:
Applications will be able to read mixed-case expressions.
Programmers will be able to make use of case distinctions.
Aesthetics:
For the proposal:
The language will have greater symmetry, because it will be
possible to control the treatment of case on both input and output
instead of only on output (as is now the case).
The language will look less old-fashioned.
Against the proposal:
It is, perhaps, inconsistent to control case-sensitivity by a
readtable operation when other aspects of the reader, such as the
input base and the default float format (not to mention the
package), are controlled by special variables. However, it can be
argued that character-level syntax is determined chiefly by the
readtable. Case-sensitivity can be seen as analogous to character
macros in this respect.
Discussion:
Dalton supports the proposal READTABLE-KEYWORDS.
Version 1 of the proposal suggested a new global variable rather
than a property of the readtable. Pitman was strongly opposed to
that proposal and gave convincing arguments that it should be
dropped. Gray suggested that the readtable property should be a
function. Versions 2 and 3 included a FUNCTION proposal as well
as the KEYWORD one. But at the March 1989 X3J13 meeting it was
felt that there should be only a single proposal and, since
opinion seemed to favor the KEYWORD proposal, the FUNCTION
proposal was dropped.
In earlier versions of the proposal, :INVERT worked a letter at
a time (rather than operating on extended tokens) so that, for
example, Zebra read as zEBRA. However, the purpose of :INVERT
is to let the programmer get the standard internal case (ie,
upper case) by writing lower case rather than upper. This
matters when referring to single-case symbols such as those
in the LISP package. But, in most cases, mixed-case identifiers
will already have the right case. For example, one would use
TheNextWindow to get TheNextWindow, not tHEnEXTwINDOW.
∂24-Jun-89 0549 CL-Cleanup-mailer Issue: READ-CASE-SENSITIVITY (Version 6)
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 24 Jun 89 05:49:12 PDT
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP
id aa03445; 24 Jun 89 13:22 BST
Date: Sat, 24 Jun 89 13:33:10 BST
Message-Id: <5419.8906241233@aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: Issue: READ-CASE-SENSITIVITY (Version 6)
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
In-Reply-To: Jeff Dalton's message of Fri, 23 Jun 89 21:30:23 BST
Cc: Moon@stony-brook.scrc.symbolics.com, cl-cleanup@sail.stanford.edu
I just noticed that I made a mistake in Version 5 when describing the
effect of :INVERT on escaping. I'm sorry for all the last minute
corrections. Maybe this time I'll get it sufficiently correct.
Issue: READ-CASE-SENSITIVITY
Forum: Cleanup
References: CLtL p 334 ff: What the Read Function Accepts,
especially p 337, step 8, point 1.
CLtL p 360 ff: The Readtable
COPY-READTABLE (CLtL, p 361)
*PRINT-CASE* (CLtL, p 372)
Category: ADDITION/CHANGE
Edit history: Version 1, 15-Feb-89, by Dalton
Version 2, 23-Mar-89, by Dalton,
(completely new proposal after comments from
Pitman, Gray, Masinter, and R.Tobin@uk.ac.ed)
Version 3, 16-Jun-89, by Dalton
(very minor changes in presentation
and some additions to the discussion)
Version 4, 22-Jun-89, by Dalton
(removal of the FUNCTION proposal and a different
specification for :INVERT after discussion with Moon)
Version 5, 23-Jun-89, by Dalton
(minor revisions in presentation and better test case,
as suggested by Pitman; also fixed some errors)
Version 6, 24-Jun-89, by Dalton (small correction)
Problem Description:
The Common Lisp reader always converts unescaped constituent
characters to upper case. (See CLtL, p 337, step 8, point 1.)
This behavior is not always desirable.
1. Lisp applications often use the Lisp reader to read their data.
This is often significantly easier than writing input routines
from scratch, especially if the input can be structured as lists.
However, certain applications want to make use of case distinctions,
and Common Lisp makes this unreasonably difficult. (You must define
every letter as a read macro and have the macro function read the
rest of the symbol, or else you must write a reader from scratch.)
2. Some programming languages distinguish between upper and lower
case in identifiers, and useful conventions are often built around
such distinctions. For example, in C, constants are often written
in upper case and variables in lower. In Mesa(?) and Smalltalk(?),
a capital letter is used to indicate the beginning of a new word
in identifiers made up of several words. In Edinburgh Prolog,
variables begin with upper-case letters and constant symbols do
not. The case-insensitivity of the Common Lisp reader makes
it difficult to use conventions of this sort.
Proposal (READ-CASE-SENSITIVITY:READTABLE-KEYWORDS)
Define a new settable function, (READTABLE-CASE <readtable>) to
control the reader's interpretation of case. The following values
may be given: :UPCASE, :DOWNCASE, :PRESERVE, and :INVERT.
When the value is :UPCASE, unescaped constituent characters
are converted to upper-case, as specified by CLtL on page 337.
When the value is :DOWNCASE, unescaped constituent characters
are converted to lower-case.
When the value is :PRESERVE, the case of all characters remains
unchanged.
When the value is :INVERT, then if all of the unescaped letters
in the extended token are of the same case, those (unescaped)
letters are converted to the opposite case.
COPY-READTABLE copies the setting of READTABLE-CASE. The value of
READTABLE-CASE for the standard readtable is :UPCASE.
The READTABLE-CASE of a readtable also has significance when printing
The case in which letters are printed, when vertical-bar syntax is not
used, is determined as follows:
When READTABLE-CASE is :UPCASE, upper-case letters are printed
in the case specified by *PRINT-CASE*, and lower-case letters
are printed in their own case.
When READTABLE-CASE is :DOWNCASE, lower-case letters are printed
in the case specified by *PRINT-CASE*, and upper-case letters
are printed in their own case.
When READTABLE-CASE is :PRESERVE, all letters are printed in their
own case.
When READTABLE-CASE is :INVERT, the case of all letters in single-
case symbol names is inverted. Mixed-case symbol names are printed
as-is.
The rules for escaping letters in symbol names are also affected by
the READTABLE-CASE. If *PRINT-ESCAPE* is true, letters are escaped
as follows:
When READTABLE-CASE is :UPCASE, all lower-case letters must be
escaped.
When READTABLE-CASE is :DOWNCASE, all upper-case letters must be
escaped.
When READTABLE-CASE is :PRESERVE, no letters need be escaped.
When READTABLE-CASE is :INVERT, no letters need be escaped.
Rationale:
There are a number of different ways to achieve case-sensitivity.
This proposal is fairly simple but provides all of the functionality
that one could reasonably expect.
By using a property of the readtable, we avoid introducing a new
special variable. Any code that wishes to control all of the
reader's parameters already takes *READTABLE* into account. A new
special variable would require such code to change.
:DOWNCASE is included for symmetry with :UPCASE.
:INVERT is included so that case conventions can be used in Common
Lisp code without requiring that the names of symbols in the "LISP"
package be written in upper case. (Opinions vary as to whether is
is advisable to use such conventions, but this proposal leaves that
choice to the user.)
:INVERT has an effect only for single-case names so that mixed-
case names can be interpreted in a more straightforward way.
In order to avoid complex interactions between the case setting of
the readtable and *PRINT-CASE*, this proposal specifies a
significance for *PRINT-CASE* only when the case setting is :UPCASE
or :DOWNCASE. The meaning of *PRINT-CASE* when the readtable
setting is :DOWNCASE was chosen for its simplicity and for symmetry
with :UPCASE while still being useful.
Test Cases:
;;; Test 1 -- reading
(defun test1 ()
(let ((*readtable* (copy-readtable nil)))
(format t "READTABLE-CASE Input Symbol-name~
~%-----------------------------------~
~%")
(dolist (readtable-case '(:upcase :downcase :preserve :invert))
(setf (readtable-case *readtable*) readtable-case)
(dolist (input '("ZEBRA" "Zebra" "zebra"))
(format t "~&:~A~16T~A~24T~A"
(string-upcase readtable-case)
input
(symbol-name (read-from-string input)))))))
The output from (TEST1) should be as follows:
READTABLE-CASE Input Symbol-name
-----------------------------------
:UPCASE ZEBRA ZEBRA
:UPCASE Zebra ZEBRA
:UPCASE zebra ZEBRA
:DOWNCASE ZEBRA zebra
:DOWNCASE Zebra zebra
:DOWNCASE zebra zebra
:PRESERVE ZEBRA ZEBRA
:PRESERVE Zebra Zebra
:PRESERVE zebra zebra
:INVERT ZEBRA zebra
:INVERT Zebra Zebra
:INVERT zebra ZEBRA
;;; Test 2 -- printing
(defun test2 ()
(let ((*readtable* (copy-readtable nil))
(*print-case* *print-case*))
(format t "READTABLE-CASE *PRINT-CASE* Symbol-name Output~
~%--------------------------------------------------~
~%")
(dolist (readtable-case '(:upcase :downcase :preserve :invert))
(setf (readtable-case *readtable*) readtable-case)
(dolist (print-case '(:upcase :downcase :capitalize))
(dolist (symbol '(|ZEBRA| |Zebra| |zebra|))
(setq *print-case* print-case)
(format t "~&:~A~15T:~A~29T~A~42T~A"
(string-upcase readtable-case)
(string-upcase print-case)
(symbol-name symbol)
(prin1-to-string symbol)))))))
The output from (TEST2) should be as follows:
READTABLE-CASE *PRINT-CASE* Symbol-name Output
--------------------------------------------------
:UPCASE :UPCASE ZEBRA ZEBRA
:UPCASE :UPCASE Zebra |Zebra|
:UPCASE :UPCASE zebra |zebra|
:UPCASE :DOWNCASE ZEBRA zebra
:UPCASE :DOWNCASE Zebra |Zebra|
:UPCASE :DOWNCASE zebra |zebra|
:UPCASE :CAPITALIZE ZEBRA Zebra
:UPCASE :CAPITALIZE Zebra |Zebra|
:UPCASE :CAPITALIZE zebra |zebra|
:DOWNCASE :UPCASE ZEBRA |ZEBRA|
:DOWNCASE :UPCASE Zebra |Zebra|
:DOWNCASE :UPCASE zebra ZEBRA
:DOWNCASE :DOWNCASE ZEBRA |ZEBRA|
:DOWNCASE :DOWNCASE Zebra |Zebra|
:DOWNCASE :DOWNCASE zebra zebra
:DOWNCASE :CAPITALIZE ZEBRA |ZEBRA|
:DOWNCASE :CAPITALIZE Zebra |Zebra|
:DOWNCASE :CAPITALIZE zebra Zebra
:PRESERVE :UPCASE ZEBRA ZEBRA
:PRESERVE :UPCASE Zebra Zebra
:PRESERVE :UPCASE zebra zebra
:PRESERVE :DOWNCASE ZEBRA ZEBRA
:PRESERVE :DOWNCASE Zebra Zebra
:PRESERVE :DOWNCASE zebra zebra
:PRESERVE :CAPITALIZE ZEBRA ZEBRA
:PRESERVE :CAPITALIZE Zebra Zebra
:PRESERVE :CAPITALIZE zebra zebra
:INVERT :UPCASE ZEBRA zebra
:INVERT :UPCASE Zebra Zebra
:INVERT :UPCASE zebra ZEBRA
:INVERT :DOWNCASE ZEBRA zebra
:INVERT :DOWNCASE Zebra Zebra
:INVERT :DOWNCASE zebra ZEBRA
:INVERT :CAPITALIZE ZEBRA zebra
:INVERT :CAPITALIZE Zebra Zebra
:INVERT :CAPITALIZE zebra ZEBRA
Current Practice:
While there may not be any current implementation that supports
exactly this proposal, several implementations provide some means
for changing case sensitivity.
Franz Inc's ExCL has a function, EXCL:SET-CASE-MODE, that sets both
the "preferred case" (the case of characters in the print names of
standard symbols such as CAR) and whether or not the reader is case-
sensitive.
In Symbolics Common Lisp, the function SET-CHARACTER-TRANSLATION
can be used to make the translation of a letter be that same letter,
thus achieving case-sensitivity.
Xerox Medley has a function for setting a readtable flag that
determines case sensitivity.
Cost to Implementors:
Fairly small. The reader will be slightly slower and readtables
will be slightly more complex.
Cost to Users:
Slight. Programmers must already take into account the possibility
that *READTABLE* will be a non-standard readtable. Case-sensitivity
is no worse than character macros in this respect.
Cost of Non-Adoption:
Applications that want to read mixed-case expressions will not
be able to use the Common Lisp reader to do so (except, perhaps,
by tortuous use of read macros).
Programming styles that rely on case distinctions (without escape
characters) will effectively be impossible in Common Lisp.
Benefits:
Applications will be able to read mixed-case expressions.
Programmers will be able to make use of case distinctions.
Aesthetics:
For the proposal:
The language will have greater symmetry, because it will be
possible to control the treatment of case on both input and output
instead of only on output (as is now the case).
The language will look less old-fashioned.
Against the proposal:
It is, perhaps, inconsistent to control case-sensitivity by a
readtable operation when other aspects of the reader, such as the
input base and the default float format (not to mention the
package), are controlled by special variables. However, it can be
argued that character-level syntax is determined chiefly by the
readtable. Case-sensitivity can be seen as analogous to character
macros in this respect.
Discussion:
Dalton supports the proposal READTABLE-KEYWORDS.
Version 1 of the proposal suggested a new global variable rather
than a property of the readtable. Pitman was strongly opposed to
that proposal and gave convincing arguments that it should be
dropped. Gray suggested that the readtable property should be a
function. Versions 2 and 3 included a FUNCTION proposal as well
as the KEYWORD one. But at the March 1989 X3J13 meeting it was
felt that there should be only a single proposal and, since
opinion seemed to favor the KEYWORD proposal, the FUNCTION
proposal was dropped.
In earlier versions of the proposal, :INVERT worked a letter at
a time (rather than operating on extended tokens) so that, for
example, Zebra read as zEBRA. However, the purpose of :INVERT
is to let the programmer get the standard internal case (ie,
upper case) by writing lower case rather than upper. This
matters when referring to single-case symbols such as those
in the LISP package. But, in most cases, mixed-case identifiers
will already have the right case. For example, one would use
TheNextWindow to get TheNextWindow, not tHEnEXTwINDOW.
∂06-Jul-89 0829 CL-Cleanup-mailer Re: Portability? [i.e., not about hokey-pokey ADJUST-ARRAY]
Received: from ti.com by SAIL.Stanford.EDU with TCP; 6 Jul 89 08:29:12 PDT
Received: by ti.com id AA16262; Thu, 6 Jul 89 10:17:37 CDT
Received: from Kelvin by tilde id AA01642; Thu, 6 Jul 89 10:09:20 CDT
Message-Id: <2824729671-14202829@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 6 Jul 89 10:07:51 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Jon L White <jonl@lucid.com>
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Portability? [i.e., not about hokey-pokey ADJUST-ARRAY]
In-Reply-To: Msg of Tue, 4 Jul 89 21:22:53 PDT from Jon L White <jonl@lucid.com>
I can't get excited about this because I have been unable to imagine why
an application program would have any legitimate reason to want to do
(TYPEP something 'SIMPLE-ARRAY). Certainly you want to be able to declare
variables to be of type SIMPLE-ARRAY, and nothing is standing in the way
of that. Perhaps it should be documented that the SIMPLE-ARRAY type is
for use in declarations and is not intended for discrimination. Would any
significant functionality be lost by saying that?
∂06-Jul-89 1205 CL-Editorial-mailer COMPLEX type specifier
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 6 Jul 89 12:05:35 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Thu, 6 Jul 89 15:06:03 EDT
Date: Thu, 6 Jul 89 15:04 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: COMPLEX type specifier
To: jonl@lucid.com, cl-cleanup@sail.stanford.edu
Cc: cl-editorial@sail.stanford.edu
Message-Id: <19890706190422.5.BARMAR@OCCAM.THINK.COM>
I'm a little confused by the intention of a portion of the
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING cleanup proposal,
which I noticed when I saw it incorporated into the Working Draft.
Here's the quote:
(COMPLEX <type>) refers to all complex numbers that can result from
giving numbers of type <type> to the function COMPLEX, plus all other
complex numbers of the same specialized representation. Remember that
both the real and the imaginary parts of any such complex number must
satisfy:
(TYPEP <real-or-imag-part> '<type>).
The two sentences seem contradictory; perhaps the problem is that the
antecedent of "any such complex number" is ambiguous. It looks like the
second sentence is saying that
(typep x '(complex <type>))
implies
(and (typep (realpart x) '<type>)
(typep (imagpart x) '<type>))
But this contradicts the first sentence, which says that the (COMPLEX
<type>) specifier refers to all complex numbers of the upgraded type.
Also, there is no such similar wording in the new ARRAY type specifier
description.
Assuming (upgraded-complex-part-type 'bit) => integer, the first
sentence specifies that
(typep #c(100 200) '(complex bit)) => true
while the second sentence implies that it is false.
What was the intent of the second sentence?
barmar
∂06-Jul-89 1215 CL-Cleanup-mailer Discrimination vs declaration
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 6 Jul 89 12:15:50 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Thu, 6 Jul 89 15:16:33 EDT
Date: Thu, 6 Jul 89 15:14 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Discrimination vs declaration
To: cl-editorial@sail.stanford.edu, cl-cleanup@sail.stanford.edu
Message-Id: <19890706191457.6.BARMAR@OCCAM.THINK.COM>
Do we or do we not still have a distinction between type specifiers that
may be used for discrimination and those that may be used for
declaration. In the June 16 Working Draft (the big one that was handed
out in Palo Alto last month), on p.2-36, the sentence "Type specifiers
are used for two different purposes: declaration and discrimination" is
marked for deletion, per issue
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING. However, on p.2-44
the description of the FUNCTION type specifier says that the list form
can only be used for declaration; this comes from issue FUNCTION-TYPE.
Since FUNCTION-TYPE was passed after
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING, I suppose it has
precedence, so the sentence on p.2-36 should not be deleted (and a
description of the distinction should be added). In effect, what
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING did was get rid of the
discrimination/declaration distinction for the ARRAY and COMPLEX types,
but not for all types in general.
Does this seem right?
barmar
∂06-Jul-89 1310 CL-Editorial-mailer Re: Discrimination vs declaration
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jul 89 13:10:18 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 JUL 89 13:10:52 PDT
Date: 6 Jul 89 13:10 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Discrimination vs declaration
In-reply-to: Barry Margolin <barmar@Think.COM>'s message of Thu, 6 Jul 89
15:14 EDT
To: Barry Margolin <barmar@Think.COM>
cc: cl-editorial@sail.stanford.edu, cl-cleanup@sail.stanford.edu
Message-ID: <890706-131052-9081@Xerox>
"In effect, what
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING did was get rid of the
discrimination/declaration distinction for the ARRAY and COMPLEX types,
but not for all types in general.
"
Yes. The distinction also remains for VALUES, for example.
∂06-Jul-89 1405 CL-Cleanup-mailer COMPLEX type specifier
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 6 Jul 89 14:05:45 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 621395; 6 Jul 89 16:09:33 EDT
Date: Thu, 6 Jul 89 16:09 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: COMPLEX type specifier
To: Barry Margolin <barmar@Think.COM>
cc: jonl@lucid.com, cl-cleanup@sail.stanford.edu, cl-editorial@sail.stanford.edu
In-Reply-To: <19890706190422.5.BARMAR@OCCAM.THINK.COM>
Message-ID: <19890706200913.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 6 Jul 89 15:04 EDT
From: Barry Margolin <barmar@Think.COM>
I'm a little confused by the intention of a portion of the
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING cleanup proposal,
which I noticed when I saw it incorporated into the Working Draft.
I think I wrote the first version (v6) of that part, so I'll try to answer.
Here's the quote:
(COMPLEX <type>) refers to all complex numbers that can result from
giving numbers of type <type> to the function COMPLEX, plus all other
complex numbers of the same specialized representation. Remember that
both the real and the imaginary parts of any such complex number must
satisfy:
(TYPEP <real-or-imag-part> '<type>).
The contorted language here is because there is no :ELEMENT-TYPE argument to
the function COMPLEX.
The two sentences seem contradictory; perhaps the problem is that the
antecedent of "any such complex number" is ambiguous. It looks like the
second sentence is saying that
(typep x '(complex <type>))
implies
(and (typep (realpart x) '<type>)
(typep (imagpart x) '<type>))
I agree that this is what the second sentence is saying, and that it is
incorrect. The second sentence was added by JonL in an attempt to clarify
the first sentence, which was even more unclear at that time than it is
in the current version. That was a good try, but it turned out not to help.
I think the drafting committee should remove that sentence, rather than
attempting to repair it somehow.
Also the first sentence got broken somewhere along the way. If you look
at the definition of SUBTYPEP on COMPLEX (later in the same proposal),
(TYPEP <x> '(COMPLEX <type1>)) must imply (TYPEP <x> '(COMPLEX <type2>))
whenever <type1> is a subtype of <type2>, since (COMPLEX <type1>) is a
subtype of (COMPLEX <type2>). Therefore the first sentence must include
other specialized representations that are "smaller" than the one that
results from giving numbers of type <type> to the function COMPLEX.
Actually the first sentence can be read to include them, but it's
ambiguous, since it can also be read as saying that (COMPLEX <type>)
always refers to just one specialized representation of complex numbers.
Here is one way to redraft it:
(COMPLEX <type>) is the set of all objects <x> for which the following
form returns <true>:
(AND (TYPEP <x> 'COMPLEX)
(TYPEP (REALPART <x>) (UPGRADED-COMPLEX-PART-TYPE <type>))
(TYPEP (IMAGPART <x>) (UPGRADED-COMPLEX-PART-TYPE <type>)))
In other words, (COMPLEX <type>) refers to all the complex numbers in
any specialized representation that can result from giving numbers of type
<type> to the function COMPLEX. (COMPLEX <type>) may refer to more than
one specialized representation, since it includes all representations
specialized for any subtype of <type>.
I think the drafting committee should start from this.
Any comments?
∂06-Jul-89 1405 CL-Editorial-mailer Discrimination vs declaration
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 6 Jul 89 14:05:44 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 621373; 6 Jul 89 15:36:09 EDT
Date: Thu, 6 Jul 89 15:35 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Discrimination vs declaration
To: Barry Margolin <barmar@Think.COM>
cc: cl-editorial@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: <19890706191457.6.BARMAR@OCCAM.THINK.COM>
Message-ID: <19890706193553.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 6 Jul 89 15:14 EDT
From: Barry Margolin <barmar@Think.COM>
Do we or do we not still have a distinction between type specifiers that
may be used for discrimination and those that may be used for
declaration.
My understanding is that there are no longer any type specifiers that have
different meaning when used for discrimination than when used for declaration.
However, there are still type specifiers that are not allowed to be used
for discrimination (VALUES and the list form of FUNCTION are the two that
come to mind).
"discrimination" = TYPEP
"declaration" = THE plus the TYPE and FTYPE declarations.
∂07-Jul-89 0042 CL-Cleanup-mailer Portability? [i.e., not about hokey-pokey ADJUST-ARRAY]
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Jul 89 00:42:04 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA02288g; Fri, 7 Jul 89 00:39:48 PDT
Received: by bhopal id AA04135g; Fri, 7 Jul 89 00:41:59 PDT
Date: Fri, 7 Jul 89 00:41:59 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8907070741.AA04135@bhopal>
To: Gray@DSG.csc.ti.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: David N Gray's message of Thu, 6 Jul 89 10:07:51 CDT <2824729671-14202829@Kelvin>
Subject: Portability? [i.e., not about hokey-pokey ADJUST-ARRAY]
re: Perhaps it should be documented that the SIMPLE-ARRAY type is
for use in declarations and is not intended for discrimination. Would any
significant functionality be lost by saying that?
Well, that's an interesting crinkle in this whole discussion. The idea
of causing more variations in the for-declaration/for-discrimination
spectrum isn't appealing to me, especially since we have worked so hard to
reduce such variation in the array type specifiers. But it still
deserves some consideration.
-- JonL --
∂07-Jul-89 0255 CL-Editorial-mailer COMPLEX type specifier
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Jul 89 02:55:11 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA02516g; Fri, 7 Jul 89 02:52:32 PDT
Received: by bhopal id AA04274g; Fri, 7 Jul 89 02:54:45 PDT
Date: Fri, 7 Jul 89 02:54:45 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8907070954.AA04274@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: barmar@Think.COM, cl-cleanup@sail.stanford.edu,
cl-editorial@sail.stanford.edu
In-Reply-To: David A. Moon's message of Thu, 6 Jul 89 16:09 EDT <19890706200913.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: COMPLEX type specifier
Dave, I don't think I added the sentence you refer to -- the second one
in the paragraph Barry quoted [If I did anything with it, it was to add
or delete the phrase "Remember that ..."]. More to the point, the last
version of the proposal I have, dated 8-Oct-88 doesn't have the particular
wording Barry quoted, which is as follows:
(COMPLEX <type>) refers to all complex numbers that can result from
giving numbers of type <type> to the function COMPLEX, plus all other
complex numbers of the same specialized representation. Remember that
both the real and the imaginary parts of any such complex number must
satisfy:
(TYPEP <real-or-imag-part> '<type>).
This looks like a mixture of two different parts of the 8-Oct-88 version.
[If there was a later rewrite, then I'm missing it -- my mail from several
months around January isn't available right now, due to an unrestored
disk crash]. Anyway, the Oct 8 version reads:
1. Eliminate references to the distinction .... Instead, ...
(COMPLEX <type>) always means all complex numbers that can result by
giving numbers of type <type> to the function COMPLEX, plus all other
complex numbers of the same specialized representation.
. . .
3. Change the meaning of (TYPEP <x> '(ARRAY <type>)) to be true if
and only if <x> is a complex number of the most specialized
representation capable of holding parts of type <type>, or if <x>
is of any subtype of that representation. Both the real and imaginary
parts must satisfy (TYPEP <real-or-imag-part> '<type>).
Possibly the intent of the second sentence of part 3 was:
. . . Both the real and imaginary parts must satisfy
(TYPEP <real-or-imag-part> (UPGRADED-COMPLEX-PART-TYPE '<type>))
However, even with that fix, I agree that this sentence isn't very clear.
Your wording:
In other words, (COMPLEX <type>) refers to all the complex numbers in
any specialized representation that can result from giving numbers of type
<type> to the function COMPLEX. (COMPLEX <type>) may refer to more than
one specialized representation, since it includes all representations
specialized for any subtype of <type>.
looks good to me, especially the second sentence. What was missing from
previous versions was the clear statement that:
(COMPLEX <type>) may refer to more than
one specialized representation, since ...
The only pitfall now is whether the phrase "specialized for any subtype
of <type>." will appear to be misleading, since the type also includes
all representations specialized for any subtype of
(UPGRADED-COMPLEX-PART-TYPE <type>).
-- JonL --
∂07-Jul-89 0300 CL-Cleanup-mailer Discrimination vs declaration
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Jul 89 03:00:50 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA02523g; Fri, 7 Jul 89 02:58:19 PDT
Received: by bhopal id AA04292g; Fri, 7 Jul 89 03:00:32 PDT
Date: Fri, 7 Jul 89 03:00:32 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8907071000.AA04292@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: barmar@Think.COM, cl-editorial@sail.stanford.edu,
cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Thu, 6 Jul 89 15:35 EDT <19890706193553.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Discrimination vs declaration
re: My understanding is that there are no longer any type specifiers that have
different meaning when used for discrimination than when used for declaration.
However, there are still type specifiers that are not allowed to be used
for discrimination (VALUES and the list form of FUNCTION are the two that
come to mind).
That was certainly the goal.
-- JonL --
∂07-Jul-89 0926 CL-Cleanup-mailer COMPLEX type specifier
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 7 Jul 89 09:26:22 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 621896; 7 Jul 89 12:26:51 EDT
Date: Fri, 7 Jul 89 12:26 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: COMPLEX type specifier
To: Jon L White <jonl@lucid.com>
cc: barmar@Think.COM, cl-cleanup@sail.stanford.edu, cl-editorial@sail.stanford.edu
In-Reply-To: <8907070954.AA04274@bhopal>
Message-ID: <19890707162633.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 7 Jul 89 02:54:45 PDT
From: Jon L White <jonl@lucid.com>
the last
version of the proposal I have, dated 8-Oct-88 doesn't have the particular
wording Barry quoted
He was quoting from the draft documentation handed out at the X3J13 meeting
last week, I believe. But here is the latest version of the cleanup proposal,
for reference. The text Barry quoted does appear in here verbatim. By the
way, all passed cleanup proposals are supposed to be available at arisia.xerox.com.
We keep a local copy at Symbolics to insulate ourselves from network problems,
and probably it would be a good idea to keep a local copy at Lucid as well.
Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
References: Data types and Type specifiers: CLtL p. 11; Sect. 4.5, p.45
Functions: TYPEP and SUBTYPEP; CLtL Sect. 6.2.1, p.72
ARRAY-ELEMENT-TYPE, CLtL p. 291
The type-specifiers:
ARRAY, SIMPLE-ARRAY, VECTOR, SIMPLE-VECTOR
COMPLEX
Related Issues: SUBTYPEP-TOO-VAGUE, LIST-TYPE-SPECIFIER
Category: CHANGE
Edit history: Version 1, 13-May-88, JonL
Version 2, 23-May-88, JonL
(typo fixes, comments from moon, rearrange some discussion)
Version 3, 02-Jun-88, JonL
(flush alternate proposal ["flush-upgrading"]; consequently,
move more of discussion back to discussion section.
Version 4, 01-Oct-88, Jan Pedersen & JonL
(reduce discussion, and "cleanup" wordings)
(Version 5 edit history missing)
Version 6, 6-Oct-88, Moon
(fix typos, cover subtypep explicitly, add complex,
change name of UPGRADE-ARRAY-ELEMENT-TYPE)
Version 7, 7-Oct-88, JonL (more name and wording changes)
Version 8, 8-Oct-88, Masinter (wording, discussion)
Version 9, 31-Oct-88, JonL (major re-wording to accommodate
recent discussion; esp. re-introduce and clarify "upgrading")
Problem description:
CLtL occasionally draws a distinction between type-specifiers "for
declaration" and "for discrimination"; see CLtL, section 4.5 "Type
Specifiers That Specialize" (p.45 and following) The phrase
"for declaration" encompasses type-specifiers passed in as the
:element-type argument to MAKE-ARRAY, passed in as the <result-type>
argument to COERCE, and used in THE and DECLARE type declarations. The
phrase "for discrimination" refers to the type-specifiers passed in as
the <type> argument(s) to TYPEP and SUBTYPEP.
One consequence of this distinction is that a variable declared to be of
type <certain-type>, and all of whose assigned objects are created in
accordance with that type, may still have none of its values ever satisfy
the TYPEP predicate with that type-specifier. One type-specifier with
this property is
(ARRAY <element-type>)
for various implementation dependent values of <element-type>. For
example, in most implementations of CL, an array X created with an
element-type of (SIGNED-BYTE 5) will, depending on the vendor, either
satisfy
(TYPEP X '(ARRAY (SIGNED-BYTE 8))), or
(TYPEP X '(ARRAY T))
but (almost) never will it satisfy
(TYPEP X '(ARRAY (SIGNED-BYTE 5))).
This is entirely permissible within the scope of standardization on
MAKE-ARRAY, where an implementation is required only to construct up the
result out of "the most specialized [element] type that can nevertheless
accommodate elements of the given type [the :element-type argument]"
(see CLtL, p287). That is, an implementation may in fact only provide a
very small number of equivalence classes of element-types for storing
arrays, corresponding to its repertoire of specialized storage techniques;
and it is explicitly permitted to "upgrade" any element-type request into
one of its built-in repertoire (see also CLtL, p45, second and third
paragraphs under Section 4.5.)
As a practical matter, almost every existing implementation does some
serious upgrading of the :element-type argument given to MAKE-ARRAY.
Yet the difference between "for declaration" and "for discrimination"
has been very confusing to many people. Similarly, portability is
hindered when users do not know just how a given implementation does
upgrading.
The type specifier (COMPLEX <part-type>) also falls in the domain of CLtL
Section 4.5. Currently, only one implementation actually provides any kind
of specialized storage for complex parts; and in this case, the practical
matter is less urgent, since the kind of upgrading happening is so obvious
as to cause little or no confusion.
Proposal: (ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING)
Short Summary:
** Eliminate the distinction between type-specifiers "for declaration" and
"for discrimination". In short, change the meaning of array and
complex type specifiers in favor of the "for declaration" meaning.
** Change the meaning of TYPEP to be in accord with "for declaration"
meaning of type-specifiers.
** Add an implementation-dependent function that reveals how a given
type-specifier for array element-types is upgraded. Add another such
function that reveals how a given type-specifier for complex parts is
upgraded.
** Clarify that "upgrading" implies a movement upwards in the type-
hierarchy lattice; i.e., if <type> upgrades to <Type>, then
<Type> must be a super-type of <type>.
** Clarify that upgrading an array element-type is independent of any
other property of arrays, such as rank, adjustability, fill-pointers,
etc.
** Clarify how SUBTYPEP thus behaves on array type-specifiers.
** Define how SUBTYPEP behaves on complex type-specifiers.
Note that despite this issue's name, the detailed specifications herein
apply to the type system -- not to the behavior of MAKE-ARRAY, nor to how
arrays are actually implemented.
Details:
First, some definitions: Two type-specifiers <type1> and <type2> are said
to be "type-equivalent" if and only if each one specifies a subtype of the
other one. For example, (UNSIGNED-BYTE 5) and (MOD 32) are two different
type- specifiers that always refer to the same sets of things; hence they
are type-equivalent. But (UNSIGNED-BYTE 5) and (SIGNED-BYTE 8) are not
type- equivalent since the former refers to a proper subset of the latter.
Two type-specifiers <type1> and <type2> are said to be "type-disjoint"
if their specified intersection is null. For example, INTEGER and FLOAT
are type disjoint by definition (see CLtL p.33), and (INTEGER 3 5) and
(INTEGER 7 10) are type-disjoint because the specified ranges have no
elements in common.
*. Eliminate the distinction between types "for declaration" and "for
discrimination". In particular, elminate any such reference in the
discussion of array and complex type-specifiers; this would include
documentation patterned after the discussion in section 4.5, pp. 45-7,
especially the example on p.46 that says "See ARRAY-ELEMENT-TYPE".
Change the meaning of (ARRAY <element-type>), as well as any of the
subtypes of ARRAY (such as SIMPLE-ARRAY, VECTOR, etc.) in favor of the
"for declaration" meaning. Make the similar simplification for the
<part-type> specifiers in the COMPLEX type-specifier.
*. Change the meaning of (TYPEP <x> '(ARRAY <type>)), where <type> is not
*, to be true if and only if <x> is an array that could be the result
of giving <type> as the :element-type argument to MAKE-ARRAY. While
(ARRAY *) refers to all arrays regardless of element type, (ARRAY <type>)
refers only to those arrays that can result from giving <type> as the
:element-type argument to the function MAKE-ARRAY. Change the meanings
for (SIMPLE-ARRAY <type>) and (VECTOR <type>) in the same way.
Change the meaning of (TYPEP <x> '(COMPLEX <type>)) similarly. Thus,
(COMPLEX <type>) refers to all complex numbers that can result from
giving numbers of type <type> to the function COMPLEX, plus all other
complex numbers of the same specialized representation. Remember that
both the real and the imaginary parts of any such complex number must
satisfy:
(TYPEP <real-or-imag-part> '<type>).
*. Add the function UPGRADED-ARRAY-ELEMENT-TYPE of one argument, which
returns the element type of the most specialized array representation
capable of holding items of the given argument type. Note that except
for storage allocation consequences, it could be defined as:
(DEFUN UPGRADED-ARRAY-ELEMENT-TYPE (TYPE)
(ARRAY-ELEMENT-TYPE (MAKE-ARRAY 0 :ELEMENT-TYPE TYPE)))
Since element-type upgrading is a fundamental operation implicit in
almost every existing implementation of MAKE-ARRAY, the purpose of this
added function is primarily to reveal how an implementation does its
upgrading.
Add the function UPGRADED-COMPLEX-PART-TYPE of one argument that
returns the part type of the most specialized complex number
representation that can hold parts of the given argument type.
*. Clarify that "upgrading" implies a movement upwards in the type-
hierarchy lattice. Specifically, the type-specifier <type> must be
a subtype of (UPGRADED-ARRAY-ELEMENT-TYPE '<type>). Furthermore, if
<type1> is a subtype of <type2>, then:
(UPGRADED-ARRAY-ELEMENT-TYPE '<type1>)
must also be a subtype of:
(UPGRADED-ARRAY-ELEMENT-TYPE '<type2>).
Note however, that two type-disjoint types can in fact be upgraded into
the same thing.
Clarify that ARRAY-ELEMENT-TYPE returns the upgraded element type
for the array; in particular, any documentation patterned after
the sentence on p. 291 begining "This set may be larger than the
set requested when the array was created; for example . . ." should
be embellished with this clarification.
Similarly, the type-specifier <type> must be a subtype of
(UPGRADED-COMPLEX-PART-TYPE <type>).
*. Clarify that upgrading an array element-type is independent of any
other property of arrays, such as rank, adjustability, fill-pointers,
displacement etc. For all such properties other than rank this should
be obvious (since they are not expressible in the language of
type-specifiers); but note that unless it is also independent of rank,
it would not be consistently possible to displace arrays to those of
differing rank.
*. Clarify that SUBTYPEP on ARRAY type-specifiers is as follows:
For all type-specifiers <type1> and <type2> other than *, require
(ARRAY <type1>) and (ARRAY <type2>) to be type-equivalent if and only
if they refer to arrays of exactly the same specialized representation;
and require them to be type-disjoint if and only if they refer to arrays
of different, distinct specialized representations. This definition
follows that implicitly prescribed in CLtL.
As a consequence of the preceding change to TYPEP and of the definition
of UPGRADED-ARRAY-ELEMENT-TYPE, the two type specifiers
(ARRAY <type1>) and
(ARRAY <type2>)
are type-equivalent if and only if
(UPGRADED-ARRAY-ELEMENT-TYPE '<type1>) and
(UPGRADED-ARRAY-ELEMENT-TYPE '<type2>)
are type-equivalent. This is another way of saying that `(ARRAY <type>)
and `(ARRAY ,(UPGRADED-ARRAY-ELEMENT-TYPE '<type>)) refer to the same
set of specialized array representations.
This defines the behavior of SUBTYPEP on array type-specifiers; namely:
(SUBTYPEP '(ARRAY <type1>) '(ARRAY <type2>))
is true if and only if
(UPGRADED-ARRAY-ELEMENT-TYPE '<type1>) and
(UPGRADED-ARRAY-ELEMENT-TYPE '<type2>)
are type-equivalent.
*. Define SUBTYPEP on COMPLEX type-specifiers as follows:
For all type-specifiers <type1> and <type2> other than *,
(SUBTYPEP '(COMPLEX <type1>) '(COMPLEX <type2>))
is T T if:
1. <type1> is a subtype of <type2>, or
2. (UPGRADED-COMPLEX-PART-TYPE '<type1>) is type-equivalent
to (UPGRADED-COMPLEX-PART-TYPE '<type2>); in this case,
(COMPLEX <type1>) and (COMPLEX <type2>) both refer to the
same specialized representation.
The result is NIL T otherwise.
The small differences between the SUBTYPEP specification for ARRAY and
for COMPLEX are necessary because there is no creation function for
complexes which allows one to specify the resultant part type independently
of the actual types of the parts. Thus in the case of COMPLEX, we must
refer to the actual type of the parts, although a number can be a member
of more than one type; e.g., 17 is of type (MOD 18) as well as of type
(MOD 256); and 2.3f5 is of type SINGLE-FLOAT was well as FLOAT.
The form:
(SUBTYPEP '(COMPLEX SINGLE-FLOAT) '(COMPLEX FLOAT))
must be true in all implementations; but:
(SUBTYPEP '(ARRAY SINGLE-FLOAT) '(ARRAY FLOAT))
is true only in implementations that do not have a specialized array
representation for single-floats distinct from that for other floats.
Test cases:
Let <aet-x> and <aet-y> be two distinct type specifiers that are
definitely not type-equivalent in a given implementation, but for which
make-array will return an object of the same array type. This will be
an implementation dependent search, but in every implementation that
the proposer has tested, there will be some such types; often,
(SIGNED-BYTE 5) and (SIGNED-BYTE 8) will work.
Thus, in each case, both of the following forms return T T:
(subtypep (array-element-type (make-array 0 :element-type '<aet-x>))
(array-element-type (make-array 0 :element-type '<aet-y>)))
(subtypep (array-element-type (make-array 0 :element-type '<aet-y>))
(array-element-type (make-array 0 :element-type '<aet-x>)))
To eliminate the distinction between "for declaration" and "for
discrimination" both of the following should be true:
[A]
(typep (make-array 0 :element-type '<aet-x>)
'(array <aet-x>))
(typep (make-array 0 :element-type '<aet-y>)
'(array <aet-y>))
Since (array <aet-x>) and (array <aet-y>) are different names for
exactly the same set of objects, these names should be type-equivalent.
That implies that the following set of tests should also be true:
[B]
(subtypep '(array <aet-x>) '(array <aet-y>))
(subtypep '(array <aet-y>) '(array <aet-x>))
Additionally, to show that un-equivalent type-specifiers that use the
same specialized array type should be equivalent as element-type
specifiers, the following type tests should be true:
[C]
(typep (make-array 0 :element-type '<aet-y>)
'(array <aet-x>))
(typep (make-array 0 :element-type '<aet-x>)
'(array <aet-y>))
Rationale:
This proposal legitimizes current practice, and removes the obscure and
un-useful distinction between type-specifiers "for declaration" and
"for discrimination". The suggested changes to the interpretation of
array and complex type-specifiers follow from defining type-specifiers
as names for collections of objects, on TYPEP being a set membership
test, and SUBTYPEP a subset test on collections of objects.
Current Practice:
Every vendor's implementation that the proposer has queried has a finite
set of specialized array representations, such that two non-equivalent
element types can be found that use the same specialized array
representation; this includes Lucid, Vaxlisp, Symbolics, TI, Franz,
and Xerox. Most implementations fail tests [A] and [C] part 1, but pass
tests [A] and [C] part 2; this is a consequence of implementing the
distinction between "for declaration" and "for discrimination". Lucid
and Xerox both pass test [B], and the other implementations fail it.
The Explorer returns NIL for all six tests in [A], [B], and [C].
Allegedly, the PCLS implementation does no "upgrading"; each array
"remembers" exactly the type-specifier handed to the MAKE-ARRAY call
that created it. Thus the test cases are not applicable to PCLS,
since the precondition cannot be met (i.e., find two non-type-equivalent
type-specifiers that are non-trivially upgraded by make-array).
Only the TI Explorer offers any specialized representation for complexes;
part types of SINGLE-FLOAT and DOUBLE-FLOAT are specialized.
Cost to Implementors:
This proposal is an incompatible change to the current language
specification, but only a small amount of work should be required in
each vendor's implementation of TYPEP and SUBTYPEP.
Cost to Users:
Because of the prevalence of confusion in this area, it seems unlikely
that any user code will have to be changed. In fact, it is more likely
that some of the vendors will cease to get bug reports about MAKE-ARRAY
returning a result that isn't of "the obvious type". Since the change
is incompatible, some user code might have to be changed.
Cost of non-adoption:
Continuing confusion in the user community.
Benefits:
It will greatly reduce confusion in the user community. The fact that
(MAKE-ARRAY <n> :ELEMENT-TYPE '<type>) frequently is not of type
(ARRAY <type>) has been very confusing to almost everyone.
Portability of applications will be increased slightly, since
the behavior of
(TYPEP (MAKE-ARRAY <n> :ELEMENT-TYPE <type>) '(ARRAY <type>))
will no longer be implementation-dependent.
Esthetics:
Reducing the confusing distinction between type-specifiers "for
declaration" and "for discrimination" is a simplifying step -- it is a
much simpler rule to state that the type-specifiers actually describe
the collections of data they purport to name. Thus this is a step
towards increased elegance.
Discussion:
This issue was prompted by a lengthy discussion on the Common Lisp
mailing list. See for example a series of exchanges started on Thu,
17 Dec 87 10:48:05 PST by Jeff Barnett <jbarnett@nrtc.northrop.com>
under the subject line of "Types in CL". See also the exchange started
Wed, 6 Jan 88 23:21:16 PST by Jon L White <edsel!jonl@labrea.stanford.edu>
under the subject line of "TYPEP warp implications"
Although the types STRING, BIT-VECTOR, SIMPLE-STRING, and
SIMPLE-BIT-VECTOR are subtypes of the ARRAY type, they are not
specifically discussed in this proposal. The reason is that
they are not type-specifiers "that specialize", but are merely
abbreviations as follows:
STRING == (VECTOR STRING-CHAR)
SIMPLE-STRING == (SIMPLE-ARRAY STRING-CHAR (*))
BIT-VECTOR == (VECTOR BIT)
SIMPLE-BIT-VECTOR == (SIMPLE-ARRAY BIT (*))
Thus their semantics could be affected only in an implementation that
doesn't support a specific "specialized storage" type for arrays of
bits and vectors of string-chars. But in fact, every CL implementation
must appear to support "specialized storage" for bit-arrays and strings,
even if it means nothing more than remembering the fact that such an
array was created with that element-type. This is required in order
for strings, bit-vectors, and bit-arrays to be disjoint datatypes
(see CLtL p.34; see also the definitions of BIT-ARRAY and STRING found
in CLtL p.293, Section 17.4, and in CLtL p.299.)
We considered the possibility of flushing the permission to "upgrade";
for example, it could be made a requirement that:
(ARRAY-ELEMENT-TYPE (MAKE-ARRAY <n> :ELEMENT-TYPE <type>))
always be equal to <type> (or, at least type-equivalent to <type>)
for all valid type specifiers <type>. This has several problems: it
increases the storage requirement for many kinds of arrays, and hides
a relevant part of the underlying implementation for no apparently
good reason. However, it would increase portability, since it would be
much more difficult, for example, to write a program that created an
array with one element-type, say, (UNSIGNED-BYTE 5), but operated on it
assuming a non-trivial upgraded element-type, say, (UNSIGNED-BYTE 8).
Under this proposal, it is valid for an implementation of MAKE-ARRAY
to have arrays "remember" the type-equivalence class of the original
:element-type argument; such an implementation would satisfy all of
the constraints listed above.
We considered a suggestion to restrict the set of "known" array element
types; this would gain portability at the expense of limiting the
language.
We considered leaving out of the proposal the addition of the two
functions UPGRADED-ARRAY-ELEMENT-TYPE and UPGRADED-COMPLEX-PART-TYPE.
But it was noted that every implementation of CL supports exactly
that functionality somewhere in its implementation of MAKE-ARRAY; and
exposing this to the user would be a good thing. Furthermore, the
existence of at least UPGRADED-ARRAY-ELEMENT-TYPE makes the clarifications
on "upgrading" and SUBTYPEP implications easier. Finally, there would
be no other way at all to pinpoint just how complex parts are upgraded,
since there is no type information available except for the actual
types of the parts.
Since this proposal contains the implication:
(ARRAY <type1>) is-type-equivalent-to (ARRAY <type2>)
==>
<type1> is-type-equivalent-to <type2>
then the question naturally arises "Does the reverse implication hold?"
That is, should two non-EQ but type-equivalent type-specifiers <type1>
and <type2> always give rise to the same array types? For example,
consider SHORT-FLOAT and SINGLE-FLOAT in an implementation where these
are type-equivalent (see CLtL section 2.1.3). One may desire to implement
(ARRAY SHORT-FLOAT) and (ARRAY SINGLE-FLOAT) differently. Say, for example
that the former is packed into 16-bit half-words, whereas the latter is
packed into 32-bit words; but for either kind of packing, the result of
AREF is an ordinary "single-float". The whole point of the type-specifier
to make-array is merely to specify a packing technique for "packed float"
arrays. This "krinkle", however, will not be addressed by the proposal
herein; it should simply be remembered that the implication above goes
only one way, and is not an "if-and-only-if" link.
∂10-Jul-89 1549 CL-Cleanup-mailer SYMBOL-MACROLET
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 10 Jul 89 15:49:25 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 623104; 10 Jul 89 18:51:10 EDT
Date: Mon, 10 Jul 89 18:50 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SYMBOL-MACROLET
To: goldman@vaxa.isi.edu
cc: cl-cleanup@sail.stanford.edu, cl-object-oriented-programming@sail.stanford.edu
Message-ID: <19890710225046.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
[Common-Lisp removed in favor of more specific mailing lists.]
Date: Mon, 10 Jul 89 13:49:20 PST
From: goldman@vaxa.isi.edu
To: common-lisp@sail.stanford.edu
Subject: SYMBOL-MACROLET
Message-Id: <8907102149.AA27155@vaxa.isi.edu>
Is it the case that the expansion code for a symbol-macro, (unlike
a lexical macro introduced with MACROLET) has not means to obtain
the current lexical environment?
neil
It doesn't get to execute code in order to produce the expansion,
so obtaining the environment would be meaningless. The only question
is, does it get the lexical environment of the binding-point or the
usage-point. I posed a question like the following to several CLOS
implementors at the last X3J13 meeting.
(DEFMACRO FOO () 1)
(SYMBOL-MACROLET ((X (FOO)))
(MACROLET ((FOO () 2))
X))
Consensus seems to be that it is currently defined to return 2.
I think some people consider this a feature, though I've not seen a
serious example which shows why. Personally, I think it's a bug.
I'd rather that it return 1.
∂10-Jul-89 1603 CL-Cleanup-mailer SYMBOL-MACROLET
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 10 Jul 89 16:02:54 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 623112; 10 Jul 89 19:04:34 EDT
Date: Mon, 10 Jul 89 19:04 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SYMBOL-MACROLET
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: goldman@vaxa.isi.edu, cl-cleanup@sail.stanford.edu, cl-object-oriented-programming@sail.stanford.edu
In-Reply-To: <19890710225046.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890710230427.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 10 Jul 89 18:50 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
[Common-Lisp removed in favor of more specific mailing lists.]
Date: Mon, 10 Jul 89 13:49:20 PST
From: goldman@vaxa.isi.edu
To: common-lisp@sail.stanford.edu
Subject: SYMBOL-MACROLET
Message-Id: <8907102149.AA27155@vaxa.isi.edu>
Is it the case that the expansion code for a symbol-macro, (unlike
a lexical macro introduced with MACROLET) has not means to obtain
the current lexical environment?
neil
It doesn't get to execute code in order to produce the expansion,
so obtaining the environment would be meaningless. The only question
is, does it get the lexical environment of the binding-point or the
usage-point. I posed a question like the following to several CLOS
implementors at the last X3J13 meeting.
(DEFMACRO FOO () 1)
(SYMBOL-MACROLET ((X (FOO)))
(MACROLET ((FOO () 2))
X))
Consensus seems to be that it is currently defined to return 2.
I think some people consider this a feature, though I've not seen a
serious example which shows why. Personally, I think it's a bug.
I'd rather that it return 1.
This is no different from
(DEFMACRO FOO () 1)
(MACROLET ((X () `(FOO)))
(MACROLET ((FOO () 2))
(X)))
which also returns 2.
If Common Lisp had syntactic closures, as proposed to be added to Scheme,
then it would be possible for the definition of X to specify whether
the FOO in the expansion is closed or free, i.e. whether the name FOO
is to be resolved in the environment where the macro was defined or in
the environment where the macro was called.
Since Common Lisp does not have syntactic closures at this time, it is
consistent and appropriate for SYMBOL-MACROLET to behave the same as
MACROLET. I didn't say it was a feature, I only said it was consistent
and appropriate.
∂13-Jul-89 1224 CL-Cleanup-mailer issue DEFINE-COMPILER-MACRO
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 13 Jul 89 12:23:29 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA15589g; Thu, 13 Jul 89 12:19:58 PDT
Received: by bhopal id AA16436g; Thu, 13 Jul 89 12:22:05 PDT
Date: Thu, 13 Jul 89 12:22:05 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8907131922.AA16436@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: sandra%defun@cs.utah.edu, smh@Franz.COM, RPG@SAIL.Stanford.EDU,
masinter.pa@xerox.com, x3j13@sail.stanford.edu,
cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Thu, 13 Jul 89 12:02 EDT <19890713160237.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: issue DEFINE-COMPILER-MACRO
Like you, I think Sandra's questions (1) and (2) really are moot, in
the context of the passed proposal.
But I'm a bit unclear about her question (3) -- "Under what circumstances
does the compiler invoke the compiler macro function?" -- is this a
roundabout way of saying "When does the compiler actually call the expander
function, regardless of whether it is going to use the result or not?" If
so, then it may be the same pedantic point that we have never actually
settled for normal macros, and I don't see any value to trying to solve it
for compiler macros but leaving it unsettled for regular macros.
And about question (4) -- Under what circumstances may the compiler ignore
the result of compiler-macro expansion, and simply emit, say, a function
call -- I don't agree that the proposal is silent on this issue. It may
not cover every conceivable circumstance, but it certainly makes very clear
that NOTINLINE overrides use of the result, and that there is a special
distinguished value that the expander function may return which effectively
means "ignore the existence of this compiler-macro definition."
Actually, I don't see much to be gained by continuing a public discussion
on these minor points. Rather than see yet another self-selected committee
pop up to continue the debate, I would suggest that, you, Dave Moon, as a
member of the drafting committee simply "clarify" any points you feel are
ambiguous and troublesome. My only input is the guidelines which I think
are either implicitly or explicitly stated in the proposal and verbal
discussion at Palo Alto:
**** Compiler-macros should be a close in spirit to regular macros
as possible, except for the points just below, to reduce the
intellectual overload of yet-another-idiosyncratic-feature;
The explicit differences (drawn from the current standard
practice at Lucid, and maybe Symbolics and Franz?) are:
(1) compiler-macros do not share the symbol-function cell with
functions and regular macros; thus one may have both a
function/macro definition as well as a compiler-macro defintion
on a name, and the general rule of applicability is whether
or not the expansion is "for compiling".
(2) There is distinguished return value which if returned by a compiler
macro expansion function effective means "ignore this compiler
macro definition".
(3) Interpreters, for implementations that have distinct interpreter
and compiler, will not expand (or use) compiler macros.
Although we agree that NOTINLINE declarations override the use of
compiler macro expansion, I hope very much that this isn't a difference
from regular macro semantics. [Have we at least stated somewhere that
NOTINLINE overrides the use or regular macro expansions?]
*** It is reasonable to leave it unspecified whether or not high
safety or low speed settings in the compiler disable the use
of compiler macro expansions [actually, I mean to say, whether
or not the compiler causes a implicit NOTINLINE declarations to
occur whenever some optimize quality is active]. This was the
point I thought I was championing by moving to delete a certain
part of Steve's proposed amendments.
*** I think it would be disastrous if the compiler were permitted to
"flip a coin" to determine whether or not to use the results of
macro expansion (compiler or otherwise). The programmer ought to
have resonable control, such as through explicit NOTINLINE or
OPTIMIZE declarations. But I don't care very much what syntax
is necessary to exercise that control.
I you agree in spirit with these guidelines, and are willing to take
on the task for the drafting committee, then I will have nothing further
to say.
-- JonL --
∂12-Aug-89 2250 CL-Cleanup-mailer conditions
Received: from arisia.xerox.com by SAIL.Stanford.EDU with TCP; 12 Aug 89 22:50:06 PDT
Received: from masunter.parc.Xerox.COM by arisia.xerox.com with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA12213; Sat, 12 Aug 89 22:48:58 -0700
Received: by masunter.parc.xerox.com
(5.61+/IDA-1.2.8/gandalf) id AA06325; Sat, 12 Aug 89 22:50:29 PDT
Message-Id: <8908130550.AA06325@masunter.parc.xerox.com>
Date: Sat, 12 Aug 89 22:50:29 PDT
From: <masinter@arisia.xerox.com>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanuP@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Thu, 3 Aug 89 15:39 EDT <19890803193938.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: conditions
I cleaned up the arisia directory structure a bit. I tried to create:
cl/cleanup
cl/compiler
cl/conditions
cl/editorial
cl/loop
cleanup is in reasonably good shape; conditions are what you sent, and
the rest are a mess.
∂20-Sep-89 0826 CL-Cleanup-mailer Issue COMPLEX-ATANH-BOGUS-FORMULA
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 20 Sep 89 08:26:44 PDT
Received: from fafnir.think.com by Think.COM; Wed, 20 Sep 89 11:28:29 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 20 Sep 89 11:25:01 EDT
Received: by verdi.think.com; Wed, 20 Sep 89 11:24:48 EDT
Date: Wed, 20 Sep 89 11:24:48 EDT
From: gls@Think.COM (Guy Steele)
Message-Id: <8909201524.AA21857@verdi.think.com>
To: x3j13@sail.stanford.edu
Cc: gls@Think.COM, cl-cleanup@sail.stanford.edu
Subject: Issue COMPLEX-ATANH-BOGUS-FORMULA
I hate to bring *anything* up at this late date, but while working over the
numbers chapter second edition I have been going over this branch cut stuff
one more time, with even greater care, and have discovered that the formula
for ATANH on page 209 and again on page 213 is completely bogus. What that
computes is not anything like a hyperbolic arc tangent. It would seem that
I must have mistranscribed the APL formula in Penfield's article.
CLtL has: arctanh z = log ((1+z) sqrt(1 - (1 / z↑2)))
Should be: arctanh z = log ((1+z) sqrt(1 / (1 - z↑2)))
Note that they differ in the transposition of two operators. (Boy, am I
embarrassed.)
Clearly this must be corrected. In the meantime I have found a more
definitive treatment of complex branch cuts by W. Kahan, and I propose to
follow his recommendations. This involves correcting the formula for
ATANH, and adopting new formulas for ACOS and ACOSH that are equivalent to
the ones we have now but more perspicuous.
I would appreciate knowing very soon on an informal basis whether anyone
objects to this change, so that I can include some discussion of it in the
second edition. (Of course I'm not asking for a vote until we have an
official meeting.)
--Guy
----------------------------------------------------------------
Status: New proposal
Forum: Cleanup
Issue: COMPLEX-ATANH-BOGUS-FORMULA
References: CLtL pp. 209, 212, 213
Penfield, P. "Principal Values and Branch Cuts in
Complex APL", Proc. APL 81 Conference Proceedings,
Association for Computing Machinery, 1981
Kahan, W. "Branch Cuts for Complex Elementary
Functions, or Much Ado About Nothing's Sign Bit"
in Iserles and Powell (eds.) "The State of the Art
in Numerical Analysis", pp. 165-211, Clarendon
Press, 1987
Related issues: COMPLEX-ATAN-BRANCH-CUT, IEEE-ATAN-BRANCH-CUT
Category: CHANGE
Edit history: Version 1, 20-SEP-89, Steele
Problem description:
The formula that defines ATANH in CLtL is incorrect, apparently
because of a mistranscription of a formula from Penfield's article.
CLtL has: arctanh z = log ((1+z) sqrt(1 - (1 / z↑2)))
Should be: arctanh z = log ((1+z) sqrt(1 / (1 - z↑2)))
However, given the change to ATAN in issue COMPLEX-ATAN-BRANCH-CUT,
it seems simpler to follow Kahan's recommendation and define
arctanh z = (log(1+z) - log(1-z))/2
thereby preserving the identity i arctan z = arctanh iz .
Kahan also notes that Penfield's formula for arccosh (CLtL p. 213)
arccosh z = log(z + (z + 1) sqrt((z-1)/(z+1)))
has a gratuitous removable singularity at z=-1 and recommends
arccosh z = 2 log(sqrt((z+1)/2) + sqrt((z-1)/2))
which has the same values and is also well-defined at z=-1.
Finally, Kahan recommends a different defining formula for acos
that is more similar to that of acosh (but less similar to that
of asin).
Proposal (COMPLEX-ATANH-BRANCH-CUT:TWEAK-MORE):
(1) Replace the erroneous formula
arctanh z = log ((1+z) sqrt(1 - (1 / z↑2)))
with
arctanh z = (log(1+z) - log(1-z))/2
(2) Note that i arctan z = arctanh iz .
(3) Replace the gratuitously singular formula
arccosh z = log(z + (z + 1) sqrt((z-1)/(z+1)))
with
arccosh z = 2 log(sqrt((z+1)/2) + sqrt((z-1)/2))
(4) Adopt the formula (already in CLtL)
arccos z = (pi / 2) - arcsin z
as the official definition of arccos, and also note that the
formulas
arccos z = -i log(z + i sqrt(1 - z↑2))
(already in CLtL) and
arccos z = 2 log(sqrt((1+z)/2) + i sqrt((1-z)/2)) / i
(recommended by Kahan) are equivalent.
Rationale:
Compatibility with what seems to be becoming standard practice.
Current practice:
Implementations I have checked have a correct implementation
of ATANH rather than slavishly following the bogus CLtL formula.
Cost to Implementors:
ATANH must be rewritten. It is not a very difficult fix.
Possibly ACOSH must be rewritten. It is not a very difficult fix.
Cost to Users:
The compatibility note on p. 210 of CLtL gave users fair warning that
a change of this kind might be adopted.
Cost of non-adoption:
Possible incorrect implementations of ATANH.
Incompatibility with HP calculators.
Benefits:
Numerical analysts may find the new definition easier to use.
Esthetics:
A toss-up, except to those who care.
Discussion:
Kahan's article not only discussed formulas but also gives specific
implementation techniques for use with IEEE 754 arithmetic.
∂27-Sep-89 1806 CL-Cleanup-mailer Re: Other things we might want to clean up
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 27 Sep 89 18:06:07 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA12677; Wed, 27 Sep 89 19:07:05 -0600
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA08109; Wed, 27 Sep 89 19:07:03 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8909280107.AA08109@defun.utah.edu>
Date: Wed, 27 Sep 89 19:07:00 MDT
Subject: Re: Other things we might want to clean up
To: masinter@parc.xerox.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter@parc.xerox.com, Wed, 27 Sep 89 17:19:04 PDT
[Removed X3j13; added cl-cleanup]
I guess it depends on where you want to draw the line between
"cleanups" and "substantive changes". I've been collecting a list of
nitpicks and vaguenesses that I would like to see fixed, along with
some more major complaints about things where I think we really
screwed up. Some of the trivial things could probably be handled in
the editorial review process (if they haven't been fixed already -- I
haven't seen the second part of the ISO draft yet). I'd be content
to sit on the rest of them until the public review period, but if you
*really* want to deal with more cleanup issues I could probably come up
with a dozen or so between now and November.
-Sandra
-------
∂27-Sep-89 2030 CL-Cleanup-mailer Other things we might want to clean up
Received: from arisia.Xerox.COM by SAIL.Stanford.EDU with TCP; 27 Sep 89 20:30:00 PDT
Received: from masunter.parc.Xerox.COM by arisia.Xerox.COM with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA18514; Wed, 27 Sep 89 20:26:19 -0700
Received: by masunter.parc.xerox.com
(5.61+/IDA-1.2.8/gandalf) id AA00787; Wed, 27 Sep 89 20:30:48 PDT
Message-Id: <8909280330.AA00787@masunter.parc.xerox.com>
Date: Wed, 27 Sep 89 20:30:48 PDT
From: <masinter@parc.xerox.com>
To: sandra%defun@cs.utah.edu
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Wed, 27 Sep 89 19:07:00 MDT <8909280107.AA08109@defun.utah.edu>
Subject: Other things we might want to clean up
Reply-To: masinter@parc.xerox.com
I'm having a hard time judging without seeing your list. I don't see
any purpose served by your sitting on them. For "process", I think the
editorial review can make "obvious" fixes subject to confirmation by
the committee of the whole.
If there's any discussion on them, we can do formal proposals a la
cleanup.
∂28-Sep-89 0806 CL-Cleanup-mailer Re: Other things we might want to clean up
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 28 Sep 89 08:06:08 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA00399; Thu, 28 Sep 89 09:07:03 -0600
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA08617; Thu, 28 Sep 89 09:06:59 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8909281506.AA08617@defun.utah.edu>
Date: Thu, 28 Sep 89 09:06:58 MDT
Subject: Re: Other things we might want to clean up
To: masinter@parc.xerox.com
Cc: sandra%defun@cs.utah.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: masinter@parc.xerox.com, Wed, 27 Sep 89 20:30:48 PDT
OK. My notes are probably not intelligible to anybody other than
myself at this point, but I'll try to find time to tidy them up
sometime within the next few weeks. (I'm kind of busy right now
making last-minute tweaks to my dissertation.... :-) ) The list
might change some after I've had a chance to review the latest draft
of the standard, too.
-Sandra
-------
∂28-Sep-89 0931 CL-Cleanup-mailer Other things we might want to clean up
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 28 Sep 89 09:30:59 PDT
Received: from fafnir.think.com by Think.COM; Thu, 28 Sep 89 12:09:27 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Thu, 28 Sep 89 12:05:11 EDT
Received: by verdi.think.com; Thu, 28 Sep 89 12:05:21 EDT
Date: Thu, 28 Sep 89 12:05:21 EDT
From: gls@Think.COM (Guy Steele)
Message-Id: <8909281605.AA08662@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Cc: masinter@parc.xerox.com, sandra%defun@cs.utah.edu
In-Reply-To: Sandra J Loosemore's message of Thu, 28 Sep 89 09:06:58 MDT <8909281506.AA08617@defun.utah.edu>
Subject: Other things we might want to clean up
Given the rate at which I have found problems and the amount of material
remaining, I project finding about three or four more problems of the kind
I have have already sent mail about. As we have seen, some of these were
easily dispatched, and I expect not too much controversy over the rest.
I emphasize that I plan only to flag gaps and inconsistencies in issues
already voted upon; I will raise no new issues. Also, I'm not saying no one
else should raise new issues; I'm just trying to give Larry an estimate
of the amount of agenda time I am likely to consume (i.e., not much).
--Guy
∂29-Sep-89 0628 CL-Cleanup-mailer T as a stream
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 29 Sep 89 06:27:53 PDT
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP
id aa14856; 29 Sep 89 1:17 BST
Date: Thu, 28 Sep 89 14:56:25 BST
Message-Id: <13808.8909281356@aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: T as a stream
To: cl-cleanup@sail.stanford.edu
Someone just pointed out to me that FORMAT interprets T as
*STANDARD-OUTPUT*. For every other operation on character
streams, however, T means *TERMINAL-IO*. (Compare CLtL
P 374 (input from char streams), p 382 (output to char
streams), and p 386 (formatted output to char streams).)
Is this how it should be?
-- Jeff
∂29-Sep-89 0851 CL-Cleanup-mailer T as a stream
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 29 Sep 89 08:51:13 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 666409; 29 Sep 89 11:53:04 EDT
Date: Fri, 29 Sep 89 11:53 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: T as a stream
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <13808.8909281356@aiai.ed.ac.uk>
Message-ID: <19890929155309.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 28 Sep 89 14:56:25 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Someone just pointed out to me that FORMAT interprets T as
*STANDARD-OUTPUT*. For every other operation on character
streams, however, T means *TERMINAL-IO*. (Compare CLtL
P 374 (input from char streams), p 382 (output to char
streams), and p 386 (formatted output to char streams).)
Is this how it should be?
No.
Is this how it will stay? I think so. Cleaning this up
doesn't seem worth the incompatibility. Also if you changed
this and then said "Congratulate us. We have fixed FORMAT and
it is now no longer ugly and bizarre" you'd be laughed at all
around the town.
∂29-Sep-89 1155 CL-Cleanup-mailer Re: Other things we might want to clean up
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 29 Sep 89 11:55:43 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 666636; 29 Sep 89 14:57:18 EDT
Date: Fri, 29 Sep 89 14:57 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Other things we might want to clean up
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>, masinter@parc.xerox.com
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8909280107.AA08109@defun.utah.edu>
Message-ID: <19890929185723.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Wed, 27 Sep 89 19:07:00 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
I guess it depends on where you want to draw the line between
"cleanups" and "substantive changes". I've been collecting a list of
nitpicks and vaguenesses that I would like to see fixed, along with
some more major complaints about things where I think we really
screwed up. Some of the trivial things could probably be handled in
the editorial review process (if they haven't been fixed already -- I
haven't seen the second part of the ISO draft yet). I'd be content
to sit on the rest of them until the public review period, but if you
*really* want to deal with more cleanup issues I could probably come up
with a dozen or so between now and November.
I think it would be appropriate to deal with the major complaints, not only
the editorial nitpicks and vaguenesses, during the X3J13 review period. There
is no advantage I can see in going to the public review with a proposal that
is not the best proposal we can make. I think it makes sense for you (Sandra)
and everyone else to check your list against the draft before distributing it,
but once that's done and you're sure you believe in the list, I don't see any
advantage to keeping it to yourself, you may as well let all of X3J13 see it.
I expect Symbolics to produce a similar list of both minor and major
complaints. That is, I expect it to be a similar type of list. I don't
know whether the actual contents of the list will be similar to yours,
although it would of course be ideal if it turns out to be.
We only received the first half of the draft (i.e. what I take to be the
entire ISO draft) today, so I expect it will take between 6 and 8 weeks
from today to produce Symbolics' comments, or maybe longer if I have
trouble getting time commitments from reviewers. It wouldn't surprise
me if other organizations take a similar amount of time to comment. I
haven't read any of the draft yet, and I'm hoping to be surprised by how
many problems have been fixed, but judging from earlier drafts I would
expect the length of Symbolics' list to run to several hundred items,
with perhaps a couple of dozen in the "major substantive" category.
Larry, Symbolics' list will not exist in any form by the November X3J13
meeting, as far as I can see.
Since these lists of review comments and issues from various people will
probably have a great deal of overlap, it would probably make sense to
set up a process to collate and merge them, giving X3J13 something more
manageable to deal with. I believe the process set up at the last meeting
which I assume is still the process we are supposed to execute, even though
the schedule has slipped some, is that all X3J13 members are supposed to
read the draft and comment on it, then the drafting committee is supposed
to propose answers (no doubt shanghaing volunteers from outside the drafting
committee to work on coming up with answers) and distribute the comments
together with the answers to X3J13, which will then vote to approve or
disapprove each proposed change to the document. Is this correct?
∂16-Oct-89 2230 CL-Cleanup-mailer [wand@corwin.ccs.northeastern.edu: Call for Papers: 1990 ACM Conf. on Lisp & Functional Programming]
Received: from arisia.Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Oct 89 22:29:54 PDT
Received: from masunter.parc.Xerox.COM by arisia.Xerox.COM with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA09418; Mon, 16 Oct 89 22:29:49 -0700
Received: by masunter.parc.xerox.com
(5.61+/IDA-1.2.8/gandalf) id AA00494; Mon, 16 Oct 89 22:30:46 PDT
Message-Id: <8910170530.AA00494@masunter.parc.xerox.com>
Date: Mon, 16 Oct 89 22:30:46 PDT
From: <masinter@parc.xerox.com>
To: cl-cleanup@sail.stanford.edu
Subject: [wand@corwin.ccs.northeastern.edu: Call for Papers: 1990 ACM Conf. on Lisp & Functional Programming]
Reply-To: masinter@parc.xerox.com
I was thinking that some of the work on Common Lisp Cleanup would be a
good basis for a paper on "Lisp Design: The Endgame" or some such. The
thesis is that, while many folks deal with programming language design
in terms of basic semantics, a lot of the work we did involved making
some careful and difficult tradeoffs of efficiency, portability,
clarity, simplicity of implementation. The target conference is the
1990 ACM Conference on Lisp and Functional Programming.
I'm interested in developing such a paper; it would take several of
the cleanup issues (I'm not sure which) and the discussions involved,
and point out those places where there were some difficult choices.
Since the work reported would be the work of the "cl-cleanup"
committee, I wondered if any of you would be interested in being
co-author. (The fact that the conference in Nice has nothing to do
with my interest...) Please reply soon.
I asked Mitch Wand (program chair) about the possibility of a panel or
some other format, and the response was:
Date: Wed, 11 Oct 89 13:19:38 EDT
From: Mitchell Wand <wand@corwin.ccs.northeastern.edu>
To: masinter@parc.xerox.com
In-Reply-To: <masinter@parc.xerox.com>'s message of Thu, 5 Oct 89 23:15:58 PDT <8910060615.AA00955@masunter.parc.xerox.com>
Subject: Call for Papers: 1990 ACM Conf. on Lisp & Functional Programming
My guess is that it would be quite reasonable to submit a paper on the Common
Lisp cleanup committee & standard. I think people might be interested both in
the process (as exemplified in the discussion you sent in the message) and in
some of the outcomes.
Let me suggest that you submit this as an ordinary paper. The program
committee can then decide whether to accept it or whether it might be better
as a panel. Is that OK with you?
--Mitch
∂19-Oct-89 1920 CL-Cleanup-mailer [wand@corwin.ccs.northeastern.edu: Call for Papers: 1990 ACM Conf. on Lisp & Functional Programming]
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 Oct 89 19:18:23 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA10663g; Thu, 19 Oct 89 19:15:22 PDT
Received: by bhopal id AA14504g; Thu, 19 Oct 89 19:17:15 PDT
Date: Thu, 19 Oct 89 19:17:15 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8910200217.AA14504@bhopal>
To: masinter@parc.xerox.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <masinter@parc.xerox.com>'s message of Mon, 16 Oct 89 22:30:46 PDT <8910170530.AA00494@masunter.parc.xerox.com>
Subject: [wand@corwin.ccs.northeastern.edu: Call for Papers: 1990 ACM Conf. on Lisp & Functional Programming]
Yea, I'd be interested in co-authoring such a paper. If L&FP fails to
acccept it, then Lisp Pointers would surely print it.
I don't think merely a "Report of the Cleanup Committee" would be an
interesting paper; but rather the two questions alluded to by you and
Mitch could be a good starting point:
(1) Evolution of a Language Design as a Process (i.e., "cleanup"),
and how it may differ from language design de novo.
(2) Design Trade-offs for a Mixed Community of Users (e.,g., "Stock"
hardware, Special-Purpose hardware, Educational, Languag Design etc.)
-- JonL --
∂14-Nov-89 0730 CL-Cleanup-mailer Test message
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 14 Nov 89 07:30:02 PST
Date: Tue 14 Nov 89 09:29:44-CST
From: David D. Loeffler <AI.LOEFFLER@MCC.COM>
Subject: Test message
To: cl-cleanup-archive@SAIL.Stanford.EDU
cc: RPG@SAIL.Stanford.EDU
Message-ID: <12542186788.17.AI.LOEFFLER@MCC.COM>
This is just a test to see if the mailer at MCC can deliver a message
directly to the archive mailing list for cl-cleanup.
-------
∂05-Jan-90 1345 CL-Cleanup-mailer Issue: ASSERT-ERROR-TYPE
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 5 Jan 90 13:45:08 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Fri 5 Jan 90 15:42:30-CST
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 5 Jan 90 13:41:53 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 717056; 5 Jan 90 16:41:45 EST
Date: Fri, 5 Jan 90 16:41 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ASSERT-ERROR-TYPE
To: CL-Cleanup@SAIL.Stanford.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <19900105214158.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Kim Barrett remarks:
ASSERT says that if datum is unsupplied, a SIMPLE-ERROR is signalled. I
don't think SIMPLE-ERROR should be required, only ERROR. Nothing should be
explicitly required to signal a subtype of SIMPLE-CONDITION (except the
format-string cases for the various signalling functions, and assert with
a format-string).
I have no problem with this. We can either vote on this as is (to
reduce administrative overhead) or if it's controversial we can put this
in the form of a cleanup item. Anyone who has a strongly held opinion?
-kmp
∂05-Jan-90 1358 CL-Cleanup-mailer Issue: DEFINE-DECLARATION-SEQUENTIAL-BINDINGS
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 5 Jan 90 13:58:30 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Fri 5 Jan 90 15:50:56-CST
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 5 Jan 90 13:50:20 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 717073; 5 Jan 90 16:50:13 EST
Date: Fri, 5 Jan 90 16:50 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFINE-DECLARATION-SEQUENTIAL-BINDINGS
To: CL-Cleanup@SAIL.Stanford.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <19900105215027.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Here's another one from Kim Barrett. It's basically just addressing bugs
in the substrate provided by SYNTACTIC-ENVIRONMENT-ACCESS. This isn't in the
form of a cleanup item because we don't know quite what to do about it.
Suggestions anyone?
========
While processing sequential variables, need to be able to tell declaration
handlers which variable is being processed, so that only bound declarations
which apply to that variable will be processed. All other declarations should
do nothing at this stage.
Once all the initforms have been processed and all the bindings have been
established, need to be able to tell declaration handlers which bindings have
already had declarations processed, so that any bound declarations for those
variables will not be reprocessed.
I think it is possible to arrange things so that each declaration handler
would only need to be called twice, once with a list of names to process
bound declarations for, and once with a list of names for which bound
declarations should not be processed. To do this would require that
AUGMENT-ENVIRONMENT could return a list of environments. This may be too
hard to specify in a reasonable way though, and looks like the kludge it
probably is.
This is an example of what I [Kim] think a code-walker for LET* would
look like if this problem were fixed. Note the use of the additional
:sequential arguments not currently defined by the spec.
(defun walk-let* (form env walk-function)
(destructuring-bind (bindings &body body) (cdr form)
(setf bindings (canonicalize-let/let*-bindings bindings))
(multiple-value-bind (body decls) (parse-body body nil)
(setf decls (convert-declarations-to-decl-specs decls))
(do ((processed ()))
((endp bindings)
;; Final update of env, processing any decls which were not
;; attached to any of the variables being bound by this construct.
(setf env (augment-environment env
:variable (mapcar #'car processed)
;; THIS NEXT LINE IS IN QUESTION
:sequential <finished value>
:declare decls))
`(let* ,(nreverse processed)
(declare ,@decls)
,@(walk-progn-body body env walk-function)))
(destructuring-bind (var init) (pop bindings)
;; Walk init in current environment and record updated binding
(push (list var (walk-form init env walk-function)) processed)
;; Update environment by adding binding for var, processing only
;; decls which apply to the binding of var.
(setf env (augment-environment env
:variable (list var)
;; THIS NEXT LINE IS IN QUESTION
:sequential <processing value>
:declare decls)))))))
This is one way to solve the problem. Perhaps there are others. This
doesn't address what the arguments passed to the declaration handlers
are. Probably they need to receive data flow about these additional
pieces of information: the list of variables, the fact that they're
being handled sequentially, and something about whether they've already
been processed or whether they're being processed currently.
∂05-Jan-90 1407 CL-Cleanup-mailer Issue: CONDITION-ACCESSORS-SETFABLE
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 5 Jan 90 14:06:58 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Fri 5 Jan 90 15:57:44-CST
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 5 Jan 90 13:57:08 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 717080; 5 Jan 90 16:57:00 EST
Date: Fri, 5 Jan 90 16:57 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CONDITION-ACCESSORS-SETFABLE
To: CL-Cleanup@SAIL.Stanford.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <19900105215714.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
[Note that this is Kim's doing, not mine. He's here with a disk full
of stuff today if you're wondering what's going on. -kmp]
Issue: CONDITION-ACCESSORS-SETFABLE
Forum: Cleanup
References: Condition System, version 18
Category: CLARIFICATION
Edit History: Version 1, 1/3/90 by Kim A. Barrett
Problem Description:
It is presently unspecified whether the accessor functions defined for the
various standard condition classes may be used as places for SETF.
Proposal (CONDITION-ACCESSORS-SETFABLE:NO):
The effect of using accessor functions defined for the various standard
(i.e., pre-defined) condition classes as places for SETF is undefined.
Rational:
Conditions are used to record state at a particular point in time. Allowing
them to be modified at some later time makes little sense. The Condition
System does say that it is an error to attempt to assign a condition's slots
by using SETF.
Current Practice:
IIM does not make these functions be setfable.
Cost to Implementors:
Implementations might want to change all the DEFINE-CONDITIONs to use
:READER rather than :ACCESSOR when defining the accessor methods on the
slots is fairly trivial--however technically this issue itself does not
force the need for that change. Fixing any code which currently depends
on being able to SETF one of these accessors might be more work in some
implementations.
Cost to Users:
Programs which currently depend on being able to SETF these accessors are
already non-portable.
Benifits:
Users will know what to expect.
Discussion:
Pitman and Barrett supports proposal NO.
∂05-Jan-90 1415 CL-Cleanup-mailer Issue: CONDITION-SLOTS
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 5 Jan 90 14:15:34 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Fri 5 Jan 90 16:09:07-CST
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 5 Jan 90 14:08:31 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 717097; 5 Jan 90 17:08:19 EST
Date: Fri, 5 Jan 90 17:08 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CONDITION-SLOTS
To: CL-Cleanup@SAIL.Stanford.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <19900105220833.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
Issue: CONDITION-SLOTS
Forum: Cleanup
References: Condition System, version 18
Issue CLOS-CONDITIONS
Issue PACKAGE-CLUTTER
Category: CLARIFICATION/CHANGE
Edit History: Version 1, 1/3/90 by Kim A. Barrett
Problem Description:
Issue CLOS-CONDITIONS specifies that the macro WITH-SLOTS can be used
to provide more convenient access to the slots where slot accessors
are undesirable. Some people have taken this to mean that the
condition classes defined by the standard all contain slots whose
names are external symbols in the CL package which are STRING= to the
specified initargs for creating conditions. Other people do not believe
this to be the case, instead claiming that the use of WITH-SLOTS was
intended only for use with programmer defined conditions, and that the
only sanctioned interface for the standard condition classes is
through the use of the defined accessor functions.
If the second viewpoint holds, then we have the additional question of
what restrictions (if any) are placed on the packages of the names of any
slots in the standard condition classes.
Proposal (CONDITION-SLOTS:VISIBLE):
Define that for each of the initargs specified for any of the standard
condition classes, that class has a slot whose name is a symbol which is
exported from the CL package and is STRING= to the initarg.
Define that the names of any additional slots of any of the standard
condition classes must be neither external symbols of packages defined in
the standard nor symbols which are otherwise accessible in the CL-USER
package.
Proposal (CONDITION-SLOTS:HIDDEN):
Define that the names of (or even existence of) any `slots' which are
present in any of the standard condition classes are unspecified. Clarify
that the accessors may do slot lookup on such slots or slots by some other
name, or that there may in fact be no slot backing up the accessor (i.e.,
the accessor may perform a computation). Further define that the names of such
slots must be neither external symbols of packages defined in the standard
nor symbols which are otherwise accessible in the CL-USER package.
Rationale:
Placing restrictions on the names of slots which are not specified by the
standard is inline with the goals for issue PACKAGE-CLUTTER.
Current Practice:
IIM didn't consider this issue previously. It is probably the case that the
slot names match the initarg names in all cases, though the packages in
which the slot names appear was not carefully considered.
Pitman says that Symbolics probably already has some slot names which don't
match the initarg names.
Cost to Implementors:
Implementors which have already adopted either of these viewpoints would
have to change if the other viewpoint is adopted by X3J13. While changing
the condition definitions is pretty trivial, removing dependence on
particular slot names might be a bit of work.
Implementors who haven't considered the problem previously will now need
to do so.
Cost to Users:
Probably small. If VISIBLE is accepted, then users who hadn't
anticipated this behavior would have to worry about collisions in any
subclasses of the standard conditions they might have defined. If
HIDDEN is accepted, then users who hadn't anticipated that these
weren't slots might have to rewrite some calls to SLOT-VALUE, etc.
Neither of these situations is very high likelihood, however, since
this is currently a gray area and any programs which are depending on
either behavior currently non-portable.
Benifits:
Users will know what they can depend on.
Discussion:
Barrett and Pitman support HIDDEN.
∂05-Jan-90 1429 CL-Cleanup-mailer Issue: DEFINE-CONDITION-SYNTAX
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 5 Jan 90 14:29:17 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Fri 5 Jan 90 16:16:57-CST
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 5 Jan 90 14:16:16 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 717107; 5 Jan 90 17:16:08 EST
Date: Fri, 5 Jan 90 17:16 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFINE-CONDITION-SYNTAX
To: CL-Cleanup@SAIL.Stanford.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <19900105221621.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Issue: DEFINE-CONDITION-SYNTAX
Forum: Cleanup
References: Condition System, Version 18
CLOS Specification, 88-002R
Issue CLOS-CONDITIONS
Issue CONDITION-ACCESSORS-SETFABLE
Category: CHANGE/CLARIFICATION
Edit History: Version 1, 1/3/90 by Kim A. Barrett
Problem Description:
Issue CLOS-CONDITIONS incompatibly changed the slot specification syntax
for DEFINE-CONDITION to match the slot specification syntax for DEFCLASS.
This leaves us with two defining macros whose general forms are very
similar but which have small idiosyncratic differences.
Notes on voting:
Vote for just 1 of MORE-LIKE-DEFCLASS, INCOMPATIBLY-MORE-LIKE-DEFCLASS, or
MORE-LIKE-DEFINE-CONDITION.
In addition, vote yes or no to EMPHASIZE-READ-ONLY.
Proposal (DEFINE-CONDITION-SYNTAX:MORE-LIKE-DEFCLASS):
Define the syntax for DEFINE-CONDITION to be
DEFINE-CONDITION name ({supertype}*) [({slot}*) {option}*]
option ::= (:DEFAULT-INITARGS initarg-list) |
(:DOCUMENTATION string) |
(:REPORT exp)
The :default-initarg option is defined in the same way as for DEFCLASS. The
:documentation and :report options are unchanged.
If no supertypes are specified, then the condition being defined inherits
directly from CONDITION.
Proposal (DEFINE-CONDITION-SYNTAX:INCOMPATIBLY-MORE-LIKE-DEFCLASS):
As DEFINE-CONDITION-SYNTAX:MORE-LIKE-DEFCLASS, but make the slot
specification list required.
Proposal (DEFINE-CONDITION-SYNTAX:MORE-LIKE-DEFINE-CONDITION):
As DEFINE-CONDITION-SYNTAX:MORE-LIKE-DEFCLASS, but change the syntax of
DEFCLASS so that the slot specification list is optional.
Proposal (DEFINE-CONDITION-SYNTAX:EMPHASIZE-READ-ONLY)
As either of the above proposals, but remove the :WRITER and :ACCESSOR
slot options.
Rational:
This provides the added functionality provided by :DEFAULT-INITARGS, and
the convenience of not having to explicitly write CONDITION as the only
super for some conditions.
INCOMPATIBLY-MORE-LIKE-DEFCLASS makes the basic syntax identical, but at
the cost of an incompatible change, since the list of slot specifications
will no longer be optional.
EMPHASIZE-READ-ONLY emphasizes the point that it is an error to attempt
to assign a condition's slots using SETF. Condition objects are supposed
to be at least conceptually read-only.
Current Practice:
IIM supports the :DEFAULT-INITARGS option. They may support the behavior
specified for an empty supertype list (if they don't, then they still
require at least one supertype).
Cost to Implementors:
Supporting an empty supertype list in the specified way is probably fairly
trivial. For an implementation of conditions which is not based on an
implementation of CLOS, adding the support for :default-initargs might not
be trivial.
Cost to Users:
MORE-LIKE-DEFCLASS is upwardly compatible for the status quo.
The other two proposals will probably require some programs to be modified.
As an interim solution implementations could support MORE-LIKE-DEFCLASS and
issue warnings for cases which were incompatible with the other two
proposals.
Benefits:
Programmers would need to remember fewer idiosyncratic differences in the
syntax of two very similar and important macros.
Discussion:
Barrett supports MORE-LIKE-DEFINE-CONDITION. He thinks that
EMPHASIZE-READ-ONLY would be a good idea if there isn't too much concern
about the incompatibility issues.
Pitman supports MORE-LIKE-DEFCLASS but mostly because the CLOS crew are
a stubborn bunch and it seems more likely that we can bend the rest of the
spec to be like their polished piece of prose than vice versa.
(i.e., MORE-LIKE-DEFINE-CONDITION is technically just as good to him.)
Pitman also supports EMPHASIZE-READ-ONLY.
∂05-Jan-90 1441 CL-Cleanup-mailer Issue: PARSE-ERROR-STREAM
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 5 Jan 90 14:41:31 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Fri 5 Jan 90 16:22:02-CST
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 5 Jan 90 14:21:25 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 717111; 5 Jan 90 17:21:18 EST
Date: Fri, 5 Jan 90 17:21 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PARSE-ERROR-STREAM
To: CL-Cleanup@SAIL.Stanford.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <19900105222131.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Issue: PARSE-ERROR-STREAM
Forum: Cleanup
References: Condition System, Version 18
Issue READER-ERROR
Issue CLOS-CONDITIONS
Category: CHANGE/CLARIFICATION
Edit History: Version 1, 1/3/90 by Kim A. Barrett
Problem Description:
The recently passed issue READER-ERROR defined the new condition type
PARSE-ERROR as a subtype of STREAM-ERROR. This means that PARSE-ERROR
inherits behavior on the function STREAM-ERROR-STREAM, and has :STREAM as
the associated initarg. The description of STREAM-ERROR can be read to
imply that the value of STREAM-ERROR-STREAM is in fact a STREAM. That is,
that (TYPEP (STREAM-ERROR-STREAM c) 'STREAM) -> true. However, it is fairly
easy to imagine a program which might want to signal PARSE-ERROR under some
circumstance, but which is not using a Common Lisp stream as its source of
input.
Proposal (PARSE-ERROR-STREAM:SPLIT-TYPES):
Define that PARSE-ERROR is a subtype of ERROR, SERIOUS-CONDITION, CONDITION,
and T (thus making it disjoint from STREAM-ERROR).
Proposal (PARSE-ERROR-STREAM:EXPLICITELY-VAGUE-TYPE):
Define that any object may be supplied as the :STREAM initarg for
STREAM-ERROR. Define that the value of
(TYPEP (STREAM-ERROR-STREAM c) 'STREAM)
may or may not be true, depending on the value of the :STREAM initarg.
Proposal (PARSE-ERROR-STREAM:CHANGE-SLOT-NAME):
Rename the :STREAM initarg to STREAM-ERROR to be :SOURCE.
Rename the stream accessor for STREAM-ERROR to STREAM-ERROR-SOURCE.
Clarify that a stream error source need not be a stream.
Rational:
SPLIT-TYPES fixes the problem in the obvious way. If a program needs a
condition which inherits from both is desired, such a condition can be
trivially defined, since issue CLOS-CONDITIONS says that we now have
multiple inheritance for conditions.
EXPLICITELY-VAGUE-TYPE is the only alternative which will allow a program
to signal a PARSE-ERROR without having a Common Lisp STREAM handy.
Current Practice:
PARSE-ERROR is sufficiently new that few implementations are likely to
have added it.
Cost to Implementors:
Should be trivial.
Cost to Users:
If neither of these passes then some programs which might otherwise
reasonably signal PARSE-ERRORs will not be able to do so.
Benefits:
Aesthetics:
Of the alternatives, SPLIT-TYPES is simple and clean, while both
EXPLICITLY-VAGUE-TYPE and doing nothing are pretty bletcherous.
Discussion:
Barrett supports SPLIT-TYPES. He had some qualms about the merging when
he first saw the READER-ERROR issue, but didn't have time to think about
it much before the issue was voted on.
Pitman doesn't have a strong position but thinks this needs to be resolved.
SPLIT-TYPES sounds probably the most plausible to him.
∂05-Jan-90 1452 CL-Cleanup-mailer Issue: TYPE-OF-AND-PREDEFINED-CLASSES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 5 Jan 90 14:52:28 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Fri 5 Jan 90 16:24:18-CST
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 5 Jan 90 14:23:34 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 717118; 5 Jan 90 17:23:30 EST
Date: Fri, 5 Jan 90 17:23 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TYPE-OF-AND-PREDEFINED-CLASSES
To: CL-Cleanup@SAIL.Stanford.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <19900105222343.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
Issue: TYPE-OF-AND-PREDEFINED-CLASSES
Forum: Cleanup
References: Draft 8/29/89, sections 2.2 and 2.3
Draft 8/29/89, TYPE-OF
Issue TYPE-OF-UNDERCONSTRAINED
Issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED
Issue FUNCTION-TYPE
Condition System, Version 18
Category: Change
Edit History: Version 1, 1/2/90 by Kim A. Barrett
Problem Description:
In the 8/29/89 Draft there are three different lists of built-in type
specifiers, all of which are slightly different. Since some of the
differences seem to be simply oversights, it would probably be helpful if
they could be merged together.
The locations of these lists in the Draft are (1) Section 2.2, in the
description of the type disjointness requirements in the subsection entitled
"Type Relationships", (2) Section 2.3, in Figure 2-13 "Classes that
correspond to pre-defined type specifiers", and (3) in the description of
the function TYPE-OF.
The following table indicates which type names do not appear in all three
places. The groupings were made to facilitate the discussion below.
(1) (2) (3)
Group 1
CONDITION x x
LIST x x
LOGICAL-PATHNAME
REAL x x
RESTART x x
Group 2
SHORT-FLOAT special x
SINGLE-FLOAT special x
DOUBLE-FLOAT special x
LONG-FLOAT special x
Group 3
BROADCAST-STREAM x
CONCATENATED-STREAM x
ECHO-STREAM x
FILE-STREAM x
STRING-STREAM x
SYNONYM-STREAM x
TWO-WAY-STREAM x
Group 4
SIMPLE-BIT-VECTOR x
SIMPLE-STRING x
SIMPLE-VECTOR x
Group 5
SERIOUS-CONDITION x
SIMPLE-CONDITION x
WARNING x
Group 6
FIXNUM x
BIGNUM x
Proposal (TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND)
Change the disjointness requirements specified by bullets 3-6, 14, and 21
of Section 2.2, subsection Type Relationships, to instead reference the list
of predefined classes listed in Figure { insert figure number here,
currently 2-13 }, and say that among the predefined classes listed in that
table, only the specified subtype relationships may exist. This would
supersede issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED and the corresponding
sections of issue FUNCTION-TYPE.
Change the first constraint on TYPE-OF to be
"For any object for which (TYPEP object type) is true when type is one of
the types for which there is a corresponding predefined class listed in
Figure { insert figure number here, currently 2-13 }, the result of
TYPE-OF is a type specifier for which (SUBTYPEP (TYPE-OF object) type)
returns T T, i.e., either the type or a subtype of it (a subtype that the
implementation's SUBTYPEP can recognize)."
Change the fifth constraint on TYPE-OF to also include standard condition
types and condition types defined with DEFINE-CONDITION.
Make the following additions to the set of predefined classes.
1. Add the class CONDITION, with a class precedence list of (CONDITION T)
2. Add the class RESTART, with a class precedence list of (RESTART T).
3. Add the class LOGICAL-PATHNAME, with a class precedence list of
(LOGICAL-PATHNAME PATHNAME T).
4. Add the following classes with the specified class precedence lists:
BROADCAST-STREAM (BROADCAST-STREAM STREAM T)
CONCATENATED-STREAM (CONCATENATED-STREAM STREAM T)
ECHO-STREAM (ECHO-STREAM STREAM T)
FILE-STREAM (FILE-STREAM STREAM T)
STRING-STREAM (STRING-STREAM STREAM T)
SYNONYM-STREAM (SYNONYM-STREAM STREAM T)
TWO-WAY-STREAM (TWO-WAY-STREAM STREAM T)
Remove the 23rd bullet from Section 2.2, subsection Type Relationships,
which lists the above types as being disjoint subtypes of STREAM.
Rationale:
Changing the list of disjoint types and the first constraint on TYPE-OF to
reference the table of predefined classes merges three places with almost
identical information, resulting in simplification and improved cohesion.
Note that one effect of this is to remove the subtypes of FLOAT
(SHORT-FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, and LONG-FLOAT) from the list of
type specifiers mentioned in the first constraint on TYPE-OF, and to add the
types LIST and REAL (which are probably missing due to oversight).
Adding DEFINE-CONDITION to the fifth constraint brings it inline with the
intent of issue CLOS-CONDITIONS.
Adding CONDITION as a predefined class matches up with the disjointness
requirements specified by the Condition System, and corresponds to the
intent of issue CLOS-CONDITIONS. It could be argued that those two places
already mandate the addition of this class, but this proposal ensures that
we are agreed on that.
Adding RESTART as a predefined class matches up with the disjointness
requirements specified by the Condition System. It could be argued that
the Condition System already mandates the addition of this class, but this
proposal ensures that we are agreed on that.
Adding LOGICAL-PATHNAME as a predefined class seems inline with the
expressed intent for making it a type. It is sufficiently new that it may
simply have not been propagated to all the places that should mention it.
Adding the stream subclasses seems reasonable, since we are already
requiring them to be disjoint subtypes of STREAM.
The subtypes of FLOAT are not being added to the list of predefined types
because it is implementation-defined which of these are actually disjoint.
The disjointness requirements for the subtypes of SIMPLE-ARRAY can be
infered from other subtype and disjointness requirements. There has been
enough discussion of the type SIMPLE-ARRAY
(issue ADJUST-ARRAY-NOT-ADJUSTABLE) that any needed changes for these types
is being left for some future proposal, rather than add to the discussion
of this issue.
Nothing is being done with the three explicitely mentioned CONDITION types,
because other sections of the Standard already describe the relationships
between them.
Nothing is being done with the types FIXNUM and BIGNUM because we think
someone might object and we don't want to burden this proposal with
discussion of this particular issue. Adding these classes could be done
in a seperate proposal.
Current Practice:
Up to some "bugs" because they haven't caught up with X3J13 on some of
these yet, IIM implements this proposal.
Cost to Implementors:
Redirecting the disjointness requirements to reference the list of
predefined classes and modifying the constraints on TYPE-OF primarily
affects documentation, especially in the writing of the Standard. The
requirements on implementors are largely unchanged.
The effect of adding the various classes are probably minimal.
Implementations which already have the STREAM subtypes as distinguished
types can probably easily support them as classes too, since they are
probably implemented using DEFSTRUCT, CLOS, FLAVORS, or some other similar
mechanism, and making TYPE-OF return the right type name in this case is
probably trivial. Implementations which don't have these stream types
already have some work to do, and the necessary support for the types will
probably produce the necessary support for the other stuff. Similarly for
CONDITION, LOGICAL-PATHNAME, and RESTART.
Cost to Users:
Minimal. Most of the types mentioned here are new. The changes to TYPE-OF
would probably be an improvement for most users.
Benifits:
Fewer tables which need to be maintained while writing the Standard.
Discussion:
Barrett supports proposal UNIFY-AND-EXTEND.
An alternative to the unification would be to fix TYPE-OF by adding LIST and
REAL to the list of built-in types referenced by the first constraint and to
modify the fifth constraint to mention DEFINE-CONDITION. If neither of the
proposals in this issue pass, then an amendment to TYPE-OF-UNDERCONSTRAINED
to make these changes should be considered.
∂05-Jan-90 1506 CL-Cleanup-mailer Issue: STANDARD-REPERTOIRE-GRATUITOUS
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 5 Jan 90 15:06:30 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Fri 5 Jan 90 16:33:52-CST
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 5 Jan 90 14:33:08 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 717126; 5 Jan 90 17:33:03 EST
Date: Fri, 5 Jan 90 17:33 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STANDARD-REPERTOIRE-GRATUITOUS
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <19900105223315.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Issue: STANDARD-REPERTOIRE-GRATUITOUS
Forum: Cleanup
References: Character Committee Report, 7/25/89, Proposals 2.2.1 and 2.4.3
Category: Change
Edit history: Version 1, 1/3/90 by Kim A. Barrett
Problem Description
The Character Committee Report Proposal 2.2.1 (passed 3/89) requires
implementations to support and document a STANDARD character subrepertoire,
whose elements are the specified set of characters. This set of characters
corresponds exactly to those characters which are of type STANDARD-CHAR.
The Character Committee Report Proposal 2.4.3 (passed 6/89) states that
every character repertoire name is a type specifier.
Thus we have two atomic type specifiers for precisely the same thing. The
type STANDARD is equivelent to the type STANDARD-CHAR.
Proposal (STANDARD-REPERTOIRE-GRATUITOUS:RENAME):
Change the name of the STANDARD character subrepertoire required by
Character Proposal 2.2.1 to be STANDARD-CHAR.
Rationale:
This removes the duplication.
Current Practice:
Probably none.
Cost to Implementors:
Probably none.
Cost to Users:
Probably none.
Benefits:
Eliminates possible confusion when a person reading some code sees
(TYPEP foo 'STANDARD)
and wonders "STANDARD what? Transmission?"
Discussion:
Pitman and Barrett support this proposal (RENAME).
There was initally some concern that STANDARD-CHAR might not be a valid
repertoire name, but there are no restrictions placed on the names of
repertoires in any of the proposals in the Character Committee Report
dated 7/25/89. There is a footnote (#15) that constrains character
scripts and labels to only use Latin capitals A-Z, hyphen, and digits
0-9, which the name STANDARD-CHAR satisfies. Since this is a footnote,
it can be argued that it has no force anyway.
Unfortunately, this still doesn't remove STANDARD as a defined name
(i.e., exported symbol of the cl package) since it's used by CLOS for
what might be argued to be an equally ungeneric purpose. There's a
fair chance that somebody somewhere along the line is going to get
annoyed by the inter-package sharing that occurs due to this symbol
being present.
∂05-Jan-90 1520 CL-Cleanup-mailer Issue: LISP-SYMBOL-REDEFINITION
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 5 Jan 90 15:20:16 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Fri 5 Jan 90 16:40:01-CST
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 5 Jan 90 14:39:20 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 717135; 5 Jan 90 17:39:13 EST
Date: Fri, 5 Jan 90 17:39 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LISP-SYMBOL-REDEFINITION
To: CL-Cleanup@SAIL.Stanford.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <19900105223926.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Version 6 of this issue was already passed (Mar 89) by X3J13.
Below you'll find a new version (7) by Kim Barrett. It covers a few
cases that were not previously covered. The differences consist of
1. (CLARIFICATION) Add define-condition to item 4, defining type specifiers.
2. (CHANGE) Add item 14, defining setf methods.
3. (CHANGE) Add item 15, defining method combinations.
4. (CHANGE) Add permission to sometimes bind function named (SETF symbol).
with references updated.
Forum: Cleanup
Issue: LISP-SYMBOL-REDEFINITION
References: Cleanup issue PACKAGE-CLUTTER
CLtL pp 67-69 Defining named functions
CLtL pp 101-106 Generalized variables
Cleanup issue FUNCTION-NAME
Condition System, version 18
CLOS specification, 88-002R
Category: CLARIFICATION
Edit history: Masinter, Version 1, 17-Sep-88 from (Kolb, 14-Aug-87)
Masinter, Version 2, 7-Oct-88
Masinter, Version 3, 7-Oct-88, fix typos
van Roggen, Version 4, 13-Oct-88, undefined, not unspecified
Masinter, Version 5, 22-Nov-88, add more cases
Masinter, Version 6, 9-Apr-89, make Mar 89 X3j13 amendments
Barrett, Version 7, 3-Jan-90, add more cases
Problem description:
Is it legal to redefine Common Lisp functions? There is no explicit
prohibition, and many implementations do allow redefinition of
functions in the Lisp package.
CLtL only says that special forms can not be redefined. But this doesn't
solve the general problem of redefining system functions.
Proposal LISP-SYMBOL-REDEFINITION:MAR89-X3J13
Except where explicitly allowed, the consequences are undefined if any
of the following actions are performed on symbols in the COMMON-LISP
package:
1. Binding or altering its value (lexically or dynamically)
2. Defining or binding it as a function
3. Defining or binding it as a macro
4. Defining it as a type specifier (defstruct, defclass, define-condition,
deftype)
5. Defining it as a structure (defstruct)
6. Defining it as a declaration
7. Using it as a symbol macro
8. Altering its print name (this may already be prohibited)
9. Altering its package
10. Tracing it
11. Declaring or proclaiming it special or lexical
12. Declaring or proclaiming its type or ftype
13. Removing it from the package COMMON-LISP
14. Defining a setf method for it (defsetf, define-setf-method, defining
or binding the function named (SETF symbol))
15. Defining it as a method combination type
If such a symbol is not globally defined as a variable or a constant,
it is allowed to lexically bind it and declare the type of that binding.
If such a symbol is not defined as a function, macro, or special form,
it is allowed to (lexically) bind it as a function and to declare the
ftype of that binding and to trace that binding.
If such a symbol is not defined as a function, macro, or special form,
it is allowed to (lexically) bind it as a macro.
If such a symbol does not have a setf method defined for it, it is allowed to
(lexically) bind the function named (SETF symbol).
Examples:
The behavior of the construct:
(FLET ((OPEN (filename &key direction) (format t "Open called....")
(OPEN filename :direction direction)))
(with-open-file (x "frob" :direction ':output)
(format t "was Open called?")))
is undefined; for example, the macro expansion of with-open-file might refer
to the OPEN function and might not.
(DEFUN CAR (X) (CDR X))
might signal an error.
Rationale:
This proposal is the only simple resolution of the problem description that
we can imagine that is consistent with current implementation techniques.
Allowing arbitrary redefinition of symbols in the system would place
severe restrictions on implementations not to actually use those symbols in
macro expansions of other symbols, in function calls, etc. While some
looser restrictions might do for any particular Common Lisp implementation,
there seems to be no good way to distinguish between those symbols that are
redefinable and those that are not.
In general, programs can redefine functions safely by creating new symbols in
their own package, possibly shadowing the name.
Current practice:
Many Lisp environments have some mechanism for warning about redefinition of
Lisp symbols and preventing accidental redefinition while allowing it where
necessary (e.g., to patch the Lisp system itself, fix a bug, add an
optimization.)
Fewer check for lexical redefinition, since such redefinition is not as
dangerous. Certainly, there are some symbols that are never used in macro
expansions of the standard Common Lisp macros. However, implementations do
differ on the behavior of macro expansions.
Cost to Implementors:
This proposal clarifies the status quo -- that the consequences are undefined. It
allows and encourages implementors to check for such redefinition, but does not
require it.
Cost to Users:
This proposal clarifies that implementations are free to check for a condition
that they might not have before, and may clarify that some current user code is
non-portable.
Benefits:
This issue frequently arises. Adopting this proposal would clarify a frequent
source of question about Common Lisp.
Cost of non-adoption:
Continued questions.
Esthetics:
Disallowing all redefinition is the simplest way of disallowing the ones that
really are trouble.
Discussion:
At the March 89 X3j13 meeting, a proposed additional constraint
("Altering its property list") was removed. Presumably this means
that conformal programs are allowed to alter the property list of
symbols in the COMMON-LISP package.
"This [version 7] looks ok to me." -kmp
∂05-Jan-90 1527 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (version 8)
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 5 Jan 90 15:26:58 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Fri 5 Jan 90 16:45:23-CST
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 5 Jan 90 14:44:41 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 717141; 5 Jan 90 17:44:30 EST
Date: Fri, 5 Jan 90 17:44 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-CLUTTER (version 8)
To: CL-Cleanup@SAIL.Stanford.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <19900105224442.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Version 7 of this issue was already passed (Jan 89) by X3J13.
Below you'll find a new version (8) by Kim Barrett. It covers a case
that was not previously covered. The differences consist of
constraining implementations to not define setf methods or functions
other than those specified in the standard [paragraph 2 of the Proposal
section].
Issue: PACKAGE-CLUTTER
References: LISP, USER, SYSTEM packages (p181)
Related issues: LISP-SYMBOL-REDEFINITION, DEFPACKAGE,
MAKE-PACKAGE-USE-DEFAULT, IN-PACKAGE-FUNCTIONALITY
FUNCTION-NAME
Category: CHANGE/CLARIFICATION
Edit history: 07-Jul-88, Version 1 by Pitman
23-Sep-88, Version 2 by Masinter
5-Oct-88, Version 3 by Masinter
7-Oct-88, Version 4 by Masinter (response to KMP)
8-Dec-88, Version 5 by Masinter
(add property lists)
12-Dec-88, Version 6 by Masinter (respond to comments)
17-Mar-89, Version 7 by Masinter (as amended Jan 89 X3J13)
3-Jan-90, Version 8 by Barrett (add more cases)
Problem Description:
CLtL specifies that
``The package named LISP contains the primitives of
the Common Lisp system. Its external symbols include
all of the user-visible functions and global variables
that are present in the Common Lisp system, such as
CAR, CDR, *PACKAGE*, etc. Almost all other packages will
want to use LISP so that these symbosl will be accessible
without qualification.''
It specifies "all" but not "all and only".
Some implementations place their extensions in the Lisp package.
Nothing in CLtL explicitly prohibits this, but it leads to problems
in general. For example:
- A user defining a function by a name not mentioned in CLtL may be
surprised to clobber a system function in some implementations
- In one particular implementation, the variable HELP was a system
constant, so that ((LAMBDA (HELP) ...HELP...) "Press ? for help.")
signalled a correctable error (asking what variable to bind
instead of HELP :-).
Proposal (PACKAGE-CLUTTER:REDUCE):
Specify that, not only must the LISP package contain at least all of the
symbols listed in the standard, it will have no other external symbols.
(The LISP package may have additional internal symbols.)
External symbols of the LISP package may have function, macro, or special
form definitions, setf method definition, top level value or SPECIAL
proclamations, or type definitions only if explicitly permitted in the
specification. That is, a program is valid Common Lisp if it assumes that
this is true; for example, FBOUNDP will be false for all external symbols of
the LISP package except those documented to be functions, macros or special
forms; no setf method will be defined for such a symbol, and FBOUNDP on
(SETF symbol) will be false; BOUNDP will be false for all those except those
documented to be variables, and portable programs can use symbols in the
LISP package as local lexical variables with the presumption that the
variables are not proclaimed special, except for those variables specified
as constants or variables.
No external symbols of the LISP package may have properties with
property indicators that are either external symbols of packages
defined in the standard or are otherwise accessible in the USER
package.
This proposal constrains implementations as to what their
initial package configuration must be. That is, valid programs
can assume that the conformal Lisp implementation will not
have prohibited properties. The proposal LISP-SYMBOL-REDEFINITION
addresses the converse; that is, what user programs are allowed
to do.
Eliminate the requirement that the initial Common Lisp system
have a package named "SYSTEM". Specify that implementations may
have several other packages available, that these should be
documented. If it is appropriate, the standard might contain
as an example that implementations might have a package named
"SYSTEM".
Clarify that the "USER" package may have additional symbols interned
within it and that it may :USE other implementation-specific packages.
Examples:
#1: The symbol HELP may not be on the LISP package because it is not
mentioned in CLtL.
#2: The symbol VARIABLE is specified to be on the LISP package (because
it is a valid second argument to the DOCUMENTATION function). Since
it is not defined as a variable, type, or function, however, it will
not initially be bound, defined as a type, or defined as a function,
macro or special form.
Rationale:
If extra symbols are permitted in the LISP package, users may be surprised
by relationships between the LISP package and other packages which they
did not expect, or may be surprised by functionality that they did not
expect. The degenerate case is:
(DEFCONSTANT LISP:A 'YOU-LOSE)
(DEFCONSTANT LISP:B 'YOU-LOSE)
(DEFCONSTANT LISP:C 'YOU-LOSE)
...
(DEFCONSTANT LISP:AA 'YOU-LOSE)
(DEFCONSTANT LISP:AB 'YOU-LOSE)
(DEFCONSTANT LISP:AB 'YOU-LOSE)
...etc.
Given such an implementation, even things like (LAMBDA (X) X) are not
valid because they attempt to bind "system constants". It is necessary
that the programmer be able to know for sure that an arbitrary name is
"free for use" and best way to conveniently assure this is to require
that the LISP package be unadulterated.
As for the additional definitions, there are situations where additional
definitions would cause a problem. For example, if a symbol on the Lisp
package were declared as a special variable even though that value was
not mentioned in the standard, that variable would behave incorrectly when
used as a lexical variable. Similarly, if a symbol in the lisp package
were defined as an implementation-dependent special form, problems might
result if a user redefined or even bound (as by FLET or MACROLET) that
name.
The LISP package is the foothold from which portable programs establish
their desired environment. Careful control is desirable to make sure
everyone is starting off on the right foot.
Current Practice:
Some implementations have been known to add additional symbols (usually
functional and/or variable extensions) to the LISP package.
Several implementations have restricted the LISP package to only contain
those symbols in CLtL. (The exact set was difficult to extract because not all
LISP package symbols appeared in the index of CLtL.)
Even in those implementations that have only the prescribed symbols in CLtL,
there can be extra definitions for those symbols. For example, in Symbolics Genera,
the symbols EVALHOOK, ROOM, and APPLYHOOK
are spuriously defined as special variables, and the symbol LAMBDA is defined
as a macro.
Performance Impact:
None
Cost to Implementors:
The actual cost of moving the symbols out of the LISP package in cases
where they are not already gone is quite small. However, if any
implementation really has to do this, it may have a number of suppositions
about what is in what package, and the changes could potentially be extensive.
Cost to Users:
This change is upward compatible with any portable program, but users
of a particular implementation's extensions may be forced to find their
functions in a different package, so there may be a measurable practical
cost.
In many cases where an extension symbol FOO is simply expected to have
been directly available (due to :USE "LISP"), it will work to just just
do (IMPORT 'new-home-package-for-foo:FOO) where the user's package is
declared.
More likely the extension symbols would be moved to one or more
extensions packages, e.g. ACME-COMMON-LISP, so user packages in which
the extensions were desired could simply :USE the extensions package(s).
Implementations might want to use this way of conforming with this
proposal in order to minimize cost to users.
In many cases where an extension symbol FOO is used by explicit package
prefix, such as LISP:FOO, it should be easy to search for `LISP:FOO' or
even `LISP:' to find the cases.
Cost of Non-Adoption:
The potential for the LISP package to be adulterated and for supposedly
portable programs to have difficulty getting a foothold in some
implementations will be `noticeably non-zero'.
Benefits:
Portability of some programs will be enhanced.
Aesthetics:
This change probably supports the naive expectation of most programmers
writing portable code.
Discussion:
This proposal basically affects what implementors are allowed to do;
it says that portable programs can rely on a standard initial package
structure with the same symbols in it. A separate proposal,
LISP-SYMBOL-REDEFINITION, discusses the restrictions on portable
programs as far as redefining LISP symbols.
Whether the USER package may contain symbols other than those
specified in the standard was controversial. The smart programmer
of portable code will never rely on the contents of the
USER package. However, if someone wants a completely empty
package that uses only Lisp, it's easy and portable to create one.
While it would improve portability slightly to disallow additional internal
symbols in the LISP package (since it affects what DO-SYMBOLS will do)
explicitly prohibiting a common practice didn't seem like the best way
to discourage a possibly troublesome implementation technique.
Implementors should be especially careful about accidentally
exporting unwanted additional definitions for symbols,e.g., a variable
definition for EVALHOOK which might show through because of
an unintended name collision.
It is likely that the recently included portions of the standard (CLOS and
the signal mechanism) will reside in their own packages. These externally
defined packages should have the same constraints as outlined for
the LISP package here.
There has been a suggestion that vendor-specific extensions should
be placed in a package named like ACME-COMMON-LISP for the "Acme"
company.
A registry of packages (as well as features, modules and other global
names) would be useful, although probably not a part of the language
standard, per se.
Barrett and Pitman support superseding version 7 with version 8.
∂09-Jan-90 1452 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (version 8)
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 9 Jan 90 14:52:38 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 9 Jan 90 16:51:10-CST
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 9 Jan 90 14:50:30 PST
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 719356; 9 Jan 90 17:50:16 EST
Date: Tue, 9 Jan 90 17:54 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-CLUTTER (version 8)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19900105224442.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19900109225444.0.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
This is clearly correct.
∂09-Jan-90 1507 CL-Cleanup-mailer Issue: LISP-SYMBOL-REDEFINITION (version 7)
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 9 Jan 90 15:07:11 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 9 Jan 90 17:06:05-CST
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 9 Jan 90 15:05:23 PST
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 719371; 9 Jan 90 18:04:53 EST
Date: Tue, 9 Jan 90 18:09 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LISP-SYMBOL-REDEFINITION (version 7)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19900105223926.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19900109230932.1.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Kim's changes are clearly correct. As with PACKAGE-CLUTTER, this is
fixing things that fell in the cracks between two cleanup issues.
I would like to see the following additional amendments (if these
are not controversial, I will write up a version 8 incorporating
them; if they are controversial, I will consider proposing them
separately or dropping them).
Before:
6. Defining it as a declaration
After:
6. Defining it as a declaration (declaration, define-declaration)
Reason:
Be specific.
Before:
11. Declaring or proclaiming it special or lexical
After:
11. Declaring or proclaiming it special
Reason:
X3J13 voted down the issue that added the LEXICAL declaration.
Before:
13. Removing it from the package COMMON-LISP
After:
13. Uninterning or unexporting it from the package COMMON-LISP
Reason:
Be specific.
Before:
If such a symbol is not globally defined as a variable or a constant,
it is allowed to lexically bind it and declare the type of that binding.
After:
If such a symbol is not globally defined as a variable or a constant,
it is allowed to lexically bind it as a variable or as a symbol-macro
and declare the type of that binding.
Reason:
Symbol macros should have the same scoping rules as lexical variables.
This sentence may or may not have been intended to include symbol
macros, so let's be specific.
∂09-Jan-90 1520 CL-Cleanup-mailer Issue: STANDARD-REPERTOIRE-GRATUITOUS (Version 1)
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 9 Jan 90 15:20:25 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 9 Jan 90 17:10:07-CST
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 9 Jan 90 15:09:23 PST
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 719378; 9 Jan 90 18:09:06 EST
Date: Tue, 9 Jan 90 18:13 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STANDARD-REPERTOIRE-GRATUITOUS (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19900105223315.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19900109231342.2.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
I support this. I think it's only an accident of the process for
amending the character committee's proposals that the duplication
between STANDARD and STANDARD-CHAR was overlooked. Given that we
want to get rid of one of the two duplicate names, it's clear
that STANDARD-CHAR is a better name.
∂09-Jan-90 1535 CL-Cleanup-mailer Issue: PARSE-ERROR-STREAM (Version 1)
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 9 Jan 90 15:34:47 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 9 Jan 90 17:20:10-CST
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 9 Jan 90 15:19:25 PST
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 719384; 9 Jan 90 18:19:14 EST
Date: Tue, 9 Jan 90 18:23 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PARSE-ERROR-STREAM (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19900105222131.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19900109232348.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
I can support PARSE-ERROR-STREAM:SPLIT-TYPES. I feel that
PARSE-ERROR-STREAM:EXPLICITELY-VAGUE-TYPE and
PARSE-ERROR-STREAM:CHANGE-SLOT-NAME are clearly not acceptable.
Be careful about the language where you say that
PARSE-ERROR-STREAM:SPLIT-TYPES makes PARSE-ERROR disjoint from
STREAM-ERROR. Normally when we say that two types are disjoint we mean
that they do not have a common subtype. To say exactly the same thing
in other words, when we say that two types are disjoint we mean that
there does not exist an object that is a member of both types.
In this case it seems very likely that both implementations and user
programs will want to define a common subtype of PARSE-ERROR and
STREAM-ERROR for parsing errors connected with streams.
I would change "(thus making it disjoint from STREAM-ERROR)" to
"(thus making it not a subtype of STREAM-ERROR)". Can we get a
version 2 with this change and with only one proposal in it?
∂09-Jan-90 1545 CL-Cleanup-mailer Issue: CONDITION-SLOTS (Version 1) and a larger issue
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 9 Jan 90 15:45:38 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 9 Jan 90 17:40:34-CST
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 9 Jan 90 15:39:51 PST
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 719396; 9 Jan 90 18:39:34 EST
Date: Tue, 9 Jan 90 18:44 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CONDITION-SLOTS (Version 1) and a larger issue
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19900105220833.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19900109234417.4.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
CONDITION-SLOTS:VISIBLE is a clear violation of abstraction and
modularity and therefore I cannot support it.
I support CONDITION-SLOTS:HIDDEN, however I find its writeup
difficult to understand. Is the following rewrite acceptable?
Note that in additiion to using language more parallel to the
CONDITION-SLOTS:VISIBLE writeup and eliminating irrelevancies
and run-on sentences, I have used "specified" rather than
"standard" when referring to named entities called for by the
ANSI Common Lisp specification document; this is to avoid confusion
with the other use of the word "standard" as in STANDARD-CLASS.
Define that it is unspecified whether the specified condition classes
have slots.
Define that it is unspecified whether slots are involved in the
operation of specified functions on instances of specified condition
classes.
Define that the names of any slots of any of the specified
condition classes must be neither external symbols of packages defined in
the standard nor symbols which are otherwise accessible in the CL-USER
package.
In fact I would like to extend this issue to cover all objects, not just
conditions. I would do so by replacing the proposal with the following
text. Is this acceptable?
Define that it is unspecified whether the specified condition classes
have slots.
Define that it is unspecified whether slots are involved in the
operation of specified functions on instances of specified classes,
except when slots are specifically specified by the standard.
Define that if in a particular implementation a specified class has
slots that are not specified by the standard, the names of these slots
must be neither external symbols of packages defined in the standard
nor symbols which are otherwise accessible in the CL-USER package.
∂09-Jan-90 1553 CL-Cleanup-mailer Issue: CONDITION-ACCESSORS-SETFABLE (Version 1)
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 9 Jan 90 15:53:31 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 9 Jan 90 17:41:16-CST
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 9 Jan 90 15:40:35 PST
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 719397; 9 Jan 90 18:40:30 EST
Date: Tue, 9 Jan 90 18:45 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CONDITION-ACCESSORS-SETFABLE (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19900105215714.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19900109234511.5.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
This is obviously correct.
∂09-Jan-90 1559 CL-Cleanup-mailer Issue: ASSERT-ERROR-TYPE
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 9 Jan 90 15:58:54 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 9 Jan 90 17:43:44-CST
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 9 Jan 90 15:43:04 PST
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 719399; 9 Jan 90 18:42:57 EST
Date: Tue, 9 Jan 90 18:47 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ASSERT-ERROR-TYPE
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19900105214158.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19900109234739.6.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Kim Barrett remarks:
ASSERT says that if datum is unsupplied, a SIMPLE-ERROR is signalled. I
don't think SIMPLE-ERROR should be required, only ERROR.
He is obviously correct.
We can either vote on this as is (to
reduce administrative overhead) or if it's controversial we can put this
in the form of a cleanup item.
I think this would be best addressed as part of IIM's suite of comments on
the current draft specification, rather than as a cleanup issue. It seems
like a simple editorial mistake rather than a case where X3J13 is being
asked to change its mind about something.
∂10-Jan-90 0530 CL-Cleanup-mailer FIND-CLASS for "forward-referenced" classes?
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 10 Jan 90 05:30:13 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Wed 10 Jan 90 07:15:34-CST
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 10 Jan 90 05:14:48 PST
Received: from bhopal ([192.31.212.13]) by lucid.com id AA04817g; Wed, 10 Jan 90 05:14:42 PST
Received: by bhopal id AA16374g; Wed, 10 Jan 90 05:12:51 PST
Date: Wed, 10 Jan 90 05:12:51 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <9001101312.AA16374@bhopal>
To: x3j13@sail.stanford.edu
Cc: cl-cleanup@sail.stanford.edu
Subject: FIND-CLASS for "forward-referenced" classes?
[Apologies for double copies some of you will receive -- numerous people
are on one of these distribution lists, but not the other.]
Should FIND-CLASS find a "class" that has only been mentioned in a
forward-referenced way, as a direct-superclass of a non-finalized class?
Does the name of such "class" constitue a valid type-specifier? E.g.,
(defclass FOO (BAR) (a b c))
defines a non-finalized class named FOO, but does it define one named BAR?
Chapters 1&2 of the CLOS specification do not specify how one should
arrange to make "forward" references to superclasses work. Chapter 3
suggest somewhat indirectly an implementation technique of actually
creating a class object, to use as a stub, for such a reference. But
there seems to be no requirement that it must be implemented this way;
some implementations do it this way, and some apparently just keep
around internal lists of the class names that were referenced in a
"forward" way.
Arguing against letting FIND-CLASS return a forward-referenced-class
object is that the existence of such an actual class-object is merely an
implementational artifact, and may not even be portable. From a larger
point of view, one could ask why the mere mention of a potential class
name BAR when defining the class FOO should give any legitimate definition
for BAR; certainly when you make a forward reference to a function name,
you don't define that funcion; i.e.
(DEFUN FOO (X) (LIST (BAR X X)))
will define FOO, but not define BAR.
Arguing for letting *something* find the forward-referenced class is
the fact that when using the metaobject protocols in an implementation
that supports forward references this way, you will eventually want a
handle on the actual object.
Finally, it must be asked, what is the behaviour of the type system on
non-finalized classes (i.e., classes which have some direct, or even
non-direct, superclass that hasn't been defined yet). Clearly, TYPEP is
moot, since you can't make instances of non-finalized classes. But what
about subtypep? The answer for non-finalized class names probably should
be consistent with the answer for forward-referenced class names.
One possible alternative is simply to say that the class names (or class
objects too) don't become valid type specifiers until the class is fully
defined.
-- JonL --
∂11-Jan-90 1428 CL-Cleanup-mailer Issue: DEFINE-CONDITION-SYNTAX (Version 1)
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 11 Jan 90 14:28:13 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Thu 11 Jan 90 16:27:20-CST
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 11 Jan 90 14:26:30 PST
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 721082; 11 Jan 90 17:26:20 EST
Date: Thu, 11 Jan 90 17:28 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFINE-CONDITION-SYNTAX (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19900105221621.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19900111222843.8.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
This issue raises good points that I think were overlooked in past
discussions of unifying Conditions and CLOS.
I am neutral among MORE-LIKE-DEFCLASS, INCOMPATIBLY-MORE-LIKE-DEFCLASS,
or MORE-LIKE-DEFINE-CONDITION. The incompatibilities here (either making
the slot-specifier list optional where it's mandatory or mandatory where
it is optional) are of little concern since the adjustment is tiny. Any
one of these would be a significant improvement over the status quo.
I am definitely in favor of EMPHASIZE-READ-ONLY and not impressed by the
compatibility arguments. An existing program that is incompatible with
this either actually modifies condition objects, in which case it can't
work, or it just accidentally says :ACCESSOR but only uses the reader,
in which case it is trivial to fix.
∂12-Jan-90 1145 CL-Cleanup-mailer TEST message from Postmaster
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 12 Jan 90 11:45:26 PST
Received: from daystar.aca.mcc.com by MCC.COM with TCP/SMTP; Fri 12 Jan 90 13:22:45-CST
Date: Fri, 12 Jan 90 13:22:39 CST
Posted-Date: Fri, 12 Jan 90 13:22:39 CST
Message-Id: <9001121922.AA02205@daystar.aca.mcc.com>
Received: by daystar.aca.mcc.com (4.0/ACAv4.1i)
id AA02205; Fri, 12 Jan 90 13:22:39 CST
To: CL-Cleanup@mcc.com, CL-Window@mcc.com, Common-Lisp@mcc.com,
Common-Lisp-Object-System@mcc.com
Subject: TEST message from Postmaster
From: Common-Lisp-Request@mcc.com
Sender: loeffler@daystar.aca.mcc.com
Reply-To: Common-Lisp-Request@mcc.com
Please disregard this message. It is being send as a test to see how
many addresses the mailer bounces.
∂29-Jan-90 0839 CL-Cleanup-mailer Issue: TYPE-OF-AND-PREDEFINED-CLASSES (Version 1)
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 29 Jan 90 08:39:08 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Mon 29 Jan 90 10:36:43-CST
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 29 Jan 90 08:35:48 PST
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 731948; 26 Jan 90 19:42:08 EST
Date: Fri, 26 Jan 90 19:43 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TYPE-OF-AND-PREDEFINED-CLASSES (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19900105222343.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19900127004319.4.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
This is a complicated issue with a lot of parts and I spent a good
deal of time thinking about it. Let me offer a number of individual
comments which can then go into making a revised version of the
issue. I think that it would be a good idea to clean up the
distributed nature of the document here, but I think this cleanup
issue has some imperfections that have to be corrected first.
Indented text is quoted from the cleanup issue.
Proposal (TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND)
Change the disjointness requirements specified by bullets 3-6, 14, and 21
of Section 2.2, subsection Type Relationships, to instead reference the list
of predefined classes listed in Figure { insert figure number here,
currently 2-13 }, and say that among the predefined classes listed in that
table, only the specified subtype relationships may exist. This would
supersede issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED and the corresponding
sections of issue FUNCTION-TYPE.
Bullet 3 cannot be entirely removed, because in addition to builtin types
it also covers user-defined types created by DEFSTRUCT or DEFCLASS. The
bullet could be reworded to say that such user-defined types are disjoint
from all the predefined types that they are disjoint from.
Bullet 14 cannot be removed because it speaks of the type (VECTOR T),
which is not a class.
Before I go on, let me paraphrase this proposal as dividing Common
Lisp's predefined types into two families: the ones that are classes,
and the ones that are not. It then tries to say that the special
requirements on TYPE-OF and most of the disjointness requirements can be
expressed in terms of classes rather than in terms of types.
A useful exercise is to list all the types that are not classes (aside
from the ones whose type-specifiers are lists). I believe these are
proposed to be (after fixing bugs in the proposal, which I will list
later) (working from table 2-11):
ATOM NIL
BASE-CHARACTER SHORT-FLOAT
BASE-STRING SIGNED-BYTE
BIGNUM SIMPLE-ARRAY
BIT SIMPLE-BASE-STRING
COMPILED-FUNCTION SIMPLE-BIT-VECTOR
DOUBLE-FLOAT SIMPLE-STRING
EXTENDED-CHARACTER SIMPLE-VECTOR
FIXNUM SINGLE-FLOAT
KEYWORD STANDARD-CHAR
LONG-FLOAT UNSIGNED-BYTE
That's pretty confusing, let's try organizing them into categories:
Subtypes of FLOAT Subtypes of INTEGER Subtypes of CHARACTER
DOUBLE-FLOAT BIGNUM BASE-CHARACTER
LONG-FLOAT BIT EXTENDED-CHARACTER
SHORT-FLOAT FIXNUM STANDARD-CHAR
SINGLE-FLOAT SIGNED-BYTE
UNSIGNED-BYTE
Subtypes of ARRAY Subtypes of FUNCTION Other
BASE-STRING COMPILED-FUNCTION ATOM
SIMPLE-ARRAY NIL
SIMPLE-BASE-STRING Subtypes of SYMBOL
SIMPLE-BIT-VECTOR
SIMPLE-STRING KEYWORD
SIMPLE-VECTOR
I don't see any here that I want to propose to make into classes, except
see a remark below on the subtypes of FLOAT. If anyone sees anything
that isn't listed here that they think ought not to be a class, they
should speak up.
Change the first constraint on TYPE-OF to be
"For any object for which (TYPEP object type) is true when type is one of
the types for which there is a corresponding predefined class listed in
Figure { insert figure number here, currently 2-13 }, the result of
TYPE-OF is a type specifier for which (SUBTYPEP (TYPE-OF object) type)
returns T T, i.e., either the type or a subtype of it (a subtype that the
implementation's SUBTYPEP can recognize)."
This is the right idea except that it drops the subtypes of FLOAT, and I really
think it was X3J13's intention to specify how TYPE-OF behaves on them. Maybe
they should have been specified to be classes, with the idea that the classes
don't necessarily have proper names. Thus if in an implementation SHORT-FLOAT
and SINGLE-FLOAT are the same type, then they are also two names for the same
exact class. A program that tries to define two methods for the same generic
function, one specialized for SHORT-FLOAT and one specialized for SINGLE-FLOAT,
will only get one or the other of the two methods, which doesn't sound so bad
to me. Comments?
Change the fifth constraint on TYPE-OF to also include standard condition
types and condition types defined with DEFINE-CONDITION.
Shouldn't the standard condition types simply be defined to be classes
and added to figure 2-13? Issue CLOS-CONDITIONS pretty clearly says
they are classes, so presumably it's an accident that they are not in
that figure.
I think condition types defined with DEFINE-CONDITION should be
specified to be metaclass STANDARD-CLASS and hence already covered by
point five. Hmm, reading the discussion on CLOS-CONDITIONS, apparently
the metaclass is not actually specified. Why not?
Also missing from the list of predefined classes, but not listed in the cleanup
issue, are all the classes that were added by CLOS, which I think are:
BUILT-IN-CLASS METHOD-COMBINATION STANDARD-OBJECT
CLASS STANDARD-CLASS STRUCTURE-CLASS
GENERIC-FUNCTION STANDARD-GENERIC-FUNCTION STRUCTURE-OBJECT
METHOD STANDARD-METHOD
These should of course be added to the one unified table that this cleanup
issue is trying to create.
Rationale:
Changing the list of disjoint types and the first constraint on TYPE-OF to
reference the table of predefined classes merges three places with almost
identical information, resulting in simplification and improved cohesion.
Note that one effect of this is to remove the subtypes of FLOAT
(SHORT-FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, and LONG-FLOAT) from the list of
type specifiers mentioned in the first constraint on TYPE-OF, and to add the
types LIST and REAL (which are probably missing due to oversight).
Removing the subtypes of FLOAT is highly questionable.
LIST isn't needed because CONS and NULL form an exhaustive partition of it.
REAL is missing by oversight (since RATIONAL and FLOAT do -not- form
an exhaustive partition of it).
Adding DEFINE-CONDITION to the fifth constraint brings it inline with the
Typo, that should be just CONDITION.
Nothing is being done with the types FIXNUM and BIGNUM because we think
someone might object and we don't want to burden this proposal with
discussion of this particular issue. Adding these classes could be done
in a seperate proposal.
This makes it sound like you are changing something about FIXNUM and BIGNUM.
In fact this proposal leaves them exactly unchanged, and I think we should
keep it that way.
I think I would support this proposal if it wasn't buggy.